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A. Executive Summary 

This document describes the Technical Data Interoperability (TDI) Pathfinder Via Emerging 
Standards project, which was performed for NASA IT Labs and also supported by the NASA 
Office of Chief Information Officer (OCIO). This project evaluated and tested a suite of 
industry standards for a proof of concept. 

A-l Overview 

The TDI project ("TDI") investigates trending technical data standards for applicability to 
NASA vehicles, space stations, payloads, facilities, and equipment. TDI tested COTS 
software compatible with a certain suite of related industry standards for capabilities of 
individual benefits and interoperability. These standards not only esnable Information 
Technology (IT) efficiencies, but also address efficient structures and standard content 
for business processes. We used source data from generic industry samples as well as 
NASA and European Space Agency (ESA) data from space systems. 

The TDI project setup a system to simulate data exchanges by importing and exporting 
technical data between different life cycle phases, using standards-based software for: 

• Product Data Management (PDM) and Computer Aided Design (CAD) - ISO 

10303 AP203 and AP214. 

• Product Life Cycle Support (PLCS) - ISO 10303 AP239. 

• Logistic Support Analysis (LSA) - S3000L and GEIA-STD-0007. 

• Technical Publications (a.k.a. "Tech Pubs", which includes work procedures, 
technical manuals, and training documents) - S1000D. 

A-2 Problem Statement 

Most NASA technical data systems still function with silo tools and methods which are 
inefficient in themselves or not compatible between systems or products. Data is often 
re-created or requires excessive searching. Long-term archiving and retrieval strategies 
are either non-existent or limited. Most current and past space industry systems are not 
designed for efficiency or interoperability across the whole life cycle, between design 
and Operations & Support (O&S); nor between vehicles, space stations, payloads, 
facilities, and equipment; nor between NASA centers; nor between customers and 
suppliers. 

NASA lessons learned have indicated that disparate technical data increases safety risks 
from poorly integrated elements, as outlined in the Columbia Accident Investigation 
Board (CAIB) report. 

Until recently, truly standardized interoperability was not possible. NASA wants more 
industry standards and interoperability, but sharing and breaking old ways is proving 
difficult— even with new programs. NASA policy promotes interoperability and requires 
to use industry standards where no comparable NASA standard exists. Without these, it 
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will be difficult to meet some of NASA IT's strategic goals, such as enhanced mission 
success via efficient and effective access to enterprise information and collaborative 
functionality, innovative methods to attract a productive IT workforce, and partnership 
of best practices with other government agencies and commercial partners. 

NASA agency strategic goals addressed by this project include: 

• OCT Technology Area Roadmaps: Data interoperability in TA13 (Ground & 
Launch Systems Processing) and TA11 (Modeling, Simulation, IT, & Processing). 

• KSC Technology Capability Areas: Life Cycle Optimization of Products, Projects, 
and Programs. 

• Space Technology Grand Challenges: Economical Space Access, alleviating "40% 
of the total mission cost is. ..ground and launch processing." (higher % for RLV's) 

• OSTP Focus Areas: "coordinate civilian, military, commercial, and national 

security space activities." 

If appropriate choices are not made soon, then incompatible data systems and 
inefficiently-organized data and business processes will be custom-developed and 
operated independently, and future needs will drive inefficient software and data 
conversions as well as data re-creation. The missed opportunities to fix and optimize 
NASA systems for existing and developing programs will drive Life Cycle Costs (LCC) 
higher. O&S is typically 60-72% of LCC, and it needs to interface with design. Most 
importantly, disparate technical data reduces quality and increases safety risks. 

A-3 Background 

The NASA community has made some efforts to evaluate and use industry standards for 
technical data. Some updated NASA policies and plans now include references to 
modern industry standards, yet NASA is not taking advantage of these. Evaluation of the 
International Space Station (ISS) technical data environment reveals a target-rich 
compatibility for this project. Developing projects are also prime targets. 

State-of-the-art Integrated Product/Logistic Support (IPS/I LS) interoperability has been 
developing in industry. The term ILS is used by many in international industry and 
government entities to describe details of and interaction between functional areas of 
the O&S phase, including a design interface. Product Life Cycle Support (PLCS) is an 
overarching term (and a specific standard) for interoperability of data across the whole 
life cycle, connecting design technical data to O&S data. 

New and reworked standards for technical data have been released in recent years. 
More are in development. Joint agreements and efforts with international entities are 
in place, and integrated councils and work groups are working toward interoperability 
across the whole life cycle. 
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A-4 Conclusion 

The TDI project has accomplished testing for this industry concept which has not been 
attempted much in the industry. Standards-based, vendor-neutral interoperability 
between PDM, LSA, and Tech Pubs data appears to be available or developing within a 
year or two. Further testing could validate this. Real NASA/ESA data as well as industry 
sample data were tested. A conversion tool was partially developed. Though not all 
interfaces were able to exchange data as intended, lessons were learned, and a path 
forward is laid out to validate desired exchanges. 

Not all of the large list of proof-of-concept tests could be completed within the 90-day 
period for NASA IT Labs. Some challenges hindered advancement. These were 
anticipated, and additional funds were obtained to allow completion of objectives and 
possibly a few additional objectives. 

In the short term, it is recommended to continue with the unfinished proof-of-concept 
testing and development of the conversion tool. Updated results should be considered 
to incorporate into revision 1.1 of this white paper. For the long-term, it is recommend 
to carry results forward to the next level, by testing a networked integration, adding 
tests of additional functionality, adding more real data sets, and evaluating compatibility 
with work execution systems. Upon evaluation of test results described above, if results 
show good potential, then a full integration pilot should be pursued. 
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B. Project Activity 

TDI DESCRIPTION 


The TDI project ("TDI") performs a proof-of-concept of trending technical data industry 
standards which are designed for use on large, complex products, yet are also usable on 
smaller products. They apply to the IPS/ILS environment, intended to span the whole life 
cycle. These standards could also be used on space vehicles, space stations, payloads, 
facilities, and equipment. 


This project researches, evaluates, and tests these standards for their individual benefits as 
well as their interoperability. Individual benefits advertised include intelligent product 
structures, data reuse, efficient formats and processes, and industry workforce commonality. 
These related standards also tout interoperability designed into the IT, based on the 
functional business processes needed across the life cycle for maximum efficiency. One 
industry model to achieve interoperability is shown in the figure below. 



Preventive Maintenance 


Operational and 
maintenance 
data feedback 


This concept for IPS/ILS interoperability has been circulating for the last few years, but has 
yet to be fully achieved as the model is still developing. This project intends to validate part 
of this model. The standards to be evaluated are outlined in the figure above. More 
information about each standard, and other related standards, is available in the appendix. 


From a technical perspective, a common standard-based information backbone can greatly 
simplify integration complexity, by largely eliminating the need to develop and maintain 
point-to-point integration solutions. ISO 10303-239 (PLCS) has a comprehensive information 
model and the use of a Data Exchange Specification (DEX) is used to create subsets of the 
model for particular exchange needs. A DEX is a way of dividing up the huge ISO 10303-239 
PLCS information model into sections suited for a particular business process. A DEX provides 
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a subset of the PLCS information model and associated reference data and usage guidance. 
A DEX can be used to contract against or for setting conformance, but AP239 
implementations do not have to use DEXs. 

TDI SETUP 

The TDI project setup a system to simulate data exchanges by importing and exporting some 
of this technical data, using unaltered, standards-based, Commercial-Off-The-Shelf (COTS) 
software. TDI obtained vendor software compatible with targeted TDI standards, listed 
below. This software is a sampling of vendor software on the market which complies with 
these industry standards. The project also used existing software at NASA centers, listed 
below. 

• PLCS repository - Jotne's EDMtruePLM version 1.33 

o Product Life Cycle Support, ISO 10303-239 

• CAD PDM - PTC's Windchill 10.2 (development server) 

o Existing KSC system for GSDO program. 

• PLCS Adapter for Windchill PDM 

o PTC's ISO 10303 AP239 PLCS Connector trial acquired for TDI project. 

• CAD - PTC's Creo 2.0 and CreoView 3.0 

o Supports ISO 10303 AP203 & AP214 STEP neutral CAD data conversion, 
o CreoView produces proprietary light CAD files. 

• Tech Pubs - two applications for full S1000D functionality 

o Raytheon's EAGLE Publishing System (EPS) version 12 for S1000D authoring 
and CSDB management and publishing. 

o BAE Systems Trilogi View for an S1000D Interactive Electronic Technical 
Manual/Publication (IETM/IETP) viewer 

• LSA - Raytheon's EAGLE LSAR version 12 

o TDI project version 

o Supports S3000L (script added to DEF STAN 00-60 version) 
o Supports GEIA-STD-0007 

• LSA - Raytheon's EAGLE LSAR version 11 

o Version on existing JSC system for ISS 
o Supports MIL-STD-1388-2B 

• LSA - U.S. Army's PowerLOG-J version 1.7.4 (KSC evaluation copy for GSDO program) 

o Supports GEIA-STD-0007 and MIL-STD-1388-2B 
o Also imports PLCS GEIA-0007 Provisioning and Category DEX 
o Also exports TM for S1000D, RPSTL 

The NASA KSC IT Lab setup consisted of two custom-built virtual servers running Windows 
2008 Release 2 and four custom-built Windows 7 virtual clients for installation of the trial 
vendor software. One server functioned as an Oracle Database Server for management of 
the server-based EAGLE software. The other server functioned as a proprietary database 
server for management of the server-based Jotne software. Each client workstation hosted 
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the various suites of Jotne and EAGLE client-based applications depicted in the graphic below. 
The Windchill PDM and Creo CAD tools used were existing at KSC on a development server. 
The TDI test architecture and software are shown in the figure below. 



Oracle 

Database 

Server 
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be manual import/export. ■*— 
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■ Workstation 
Access 
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TEST DATA SETS 

Efforts were made to obtain available data to test from industry/vendor samples, NASA ISS, 
ESA ISS, & KSC ground systems, and manual data creation. The following data sets were 
obtained/created: 

• Industry standard sample data for a bicycle ("bike data"). Raytheon provided this data 
which was structured for S1000D work procedures and an Illustrated Parts 
Data/Breakdown (IPD/IPB) and for LSA standards GEIA-STD-0007 and S3000L (based 
on DEF STAN 00-60). . LSA data was also linked to the S1000D data for producing 
Procedural and IPD/IPB Data Modules directly from LSA data. LSA data included LCN, 
BOM, MTA, Provisioning, Reliability, Support Equipment. Tech pubs data included 
S1000D Data Modules (DM) for technical procedures and for an Illustrated Parts 
Data/Breakdown (IPD/IPB). S1000D Publication Module (PM) for the creation of an 
IETP was also included. 

• NASA ISS LSA data from JSC's EAGLE LSAR, customized based on MIL-STD-1388-2B. 
LSA-019 task analysis data was for entire Columbus Module. Data was export control 
approved. 

• NASA ISS Station Operation Data Files (SODF) procedures from JSC's International 
Procedures Viewer (IPV) library. Data was from the Columbus Module, general 
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maintenance procedures and guidelines, and warnings and cautions, provided in XML 
format. Data was export control approved. 

• NASA ISS Payload Operation Data Files (PODF) procedures from MSFC's IPV library. 
Data was from the European Module Cultivation System (EMCS), a payload from ESA. 
Data was export control approved. 

• ESA ISS original procedures and graphics from the ESA source Payload Developer (PD) 
used by NASA to develop PODFs. Data was from the EMCS. Data usage was approved 
by ESA source and partners. 

• ESA ISS PLCS product structure from Jotne. This real data is used in an ESA instance of 
EDMtruePLM for the EMCS on the ISS. Data usage was approved by ESA source and 
partners. 

• CAD data from NASA KSC ground systems of the Mobile Launcher (ML) in 
development. This data was not export control approved and was used only locally 
for testing, not to share with the whole TDI team. 

• CAD sample data of a golf cart and of an automobile, both by vendor PTC. 

• Industry sample data of 3D models in S1000D. These were obtained from the recently 
formed S1000D Model Based Enterprise Task Team (MBETT). 


TDI TESTING 

The TDI team tested as much as possible of data interoperability between different functions. 
Interoperable points on the PLCS-centered TDI concept were pursued first. Then, point-to- 
point data exchanges were tested. Finally, individual standards were evaluated for their own 
merits. The following scenarios were tested. 

PLCS Product Structure Creation and Export 

• Used industry bike data to manually load product structure in PLCS repository. The 
data was exported as DEX1. 

o RESULTS: Used this PLCS export to evaluate format and aid in creating a 
map/conversion where no adapter exists for Raytheon's LSA or S1000D tools 
to exchange with PLCS format. 
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TDI LSA GEIA-STD-0007 Export, Map for Import to PLCS 

• Exported GEIA-STD-0007 LSA bike data using a GEIA XML exchange file method. 

• Developing a conversion from GEIA-STD-0007 XML data to PLCS data in either ASCII 
(ISO-10303-21) or XML (ISO-10303-28) form, based on LOGSA-developed LSA DEX. 
Focused on product breakdown structure. 

• The LOGSA-developed LSA DEX provides a mapping between data conforming to the 
GEIA-STD-0007 LSA standard and the ISO-10303-239 PLCS standard. This DEX relies 
on templates for PLCS data, provided by the DEXlib environment, which in turn 
instantiate specific PLCS entities and attributes, as specified by the PLCS schemas, 
encoded in the EXPRESS (ISO 10303-11) language. 

• Based on team member skills and experience, as well as the broad range of available 
implementations and development tools, the extensible Stylesheet Language for 
Transformations (XSLT) was chosen as the primary tool for implementing the 
translator. XSLT transforms can consume XML data and produce either plain text (i.e., 
ISO-10303-21 ASCII format files) or XML (i.e., ISO-10303-28 XML format files) as 
output. They offer a number of features for flexible, modular development. 

• The design of the translator uses a bottom-up approach, with interchangeable XSLT 
modules for encoding PLCS output data in either text or XML format. Building upon 
these, the design will utilize existing EXPRESS parsing tools to generate XSLT modules 
containing parameterized templates for each PLCS entity and corresponding 
attributes. The PLCS DEXlib templates will be converted into a similar layer of XSLT 
modules, building on the previous layer and using a custom parser for the DEXlib 
templates' Instantiation Path syntax. Finally, the XML-based LSA DEX will be 
converted to a top-level XSLT transform that builds upon the lower-level modules to 
produce a complete translation. 
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• RESULTS: Translator development is ongoing, currently about 20% complete. 

LSA S3000L (DEF STAN 00-60) Export 

• Exported S3000L (basically DEF STAN 00-60) LSA bike data using the fullfile method. 

• RESULTS: Uncertain results. Need to run again. 

CAD Product Structure Export, Import BOM to LSA 

• Exported CAD Product Structure to get Bill of Materials (BOM) data from the PDM. 


• Golf cart data -Imported directly into EAGLE LSAR, using Raytheon's BOM import 
tool. 


o RESULTS: Creates records in 6 LSA tables and a non-standard table. See figure 
below. You cannot run an LSA BOM report immediately after a BOM import, 
because the user must perform LCN-end item UOC assignments. If no LCN, the 
import tool can auto-generate LCN's. 

Results : *■ 
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• NASA ML data (one of the most complex product structures in KSC Windchill) - 
Imported directly into EAGLE LSAR, using Raytheon's BOM import tool. 


o RESULTS: Same results as golf cart data. Importing from this complex model 
resulted in 13,293 records. An additional observation was that, the LCN 
creation tool was limited by the industry standard 18-character length, and 
can only produce classical LCN's (no option for sequential). 


CAD Data Export from PDM Using AP239 PLCS Adapter 


• PTC's AP239 PLCS Connector (adapter) was installed in KSC's Windchill 10.2 
development server called EDMS. Installation was verified with PTC. Attempts were 
made to export data from Windchill. 

o RESULTS: AP239 was not evident in the client view. It was discovered from PTC 
that their AP239 adapter does not have a user interface. They were not funded 
to support this effort, so they suggested that PTC's lnfo*Engine be used to test 
exporting. 

JSC LSA MIL-STD-1388-2B Data Exported as GEIA-STD-0007 Format 


• Exported JSC ISS LSAR data (customized based on MIL-STD-1388-2B). Used ISS 
Columbus data. 
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o Export method used was GEIA fullfile. See the figure below. Note that this 
export option does not allow selection of just one end item, nor a range of 



LCN's. We discovered later that this export method is no longer supported by 
Raytheon, and they are planning to remove the ability to produce GEIA-STD- 
0007 data from MIL-STD-1388-2B systems. See export options in screenshot 
below. 


• Import to TDI EAGLE LSA GEIA-STD-0007 Rev A Client (as GEIA format) 

o RESULTS: Data imported, recognized all LSA data tables, but there were 
specific records with import errors. The errors were suspected to be due to ISS 
EAGLE administrative customization (special character used in end item, as 
verified by Raytheon). There may be other error causes, which could not be 
identified as of yet. Before import, the GEIA revision had to be set, and the end 
item (iss_system) had to be created. Due to later discovery of the unsupported 
export method, errors would be expected with unconverted data. 

• Import to PowerLOG-J as GEIA-STD-0007 Rev A 

o RESULTS: After about 4% progress during import, the software produced an 
SAXException and stopped the import. Due to later discovery of the 
unsupported export method, it may work if imported as MIL-STD-1388-2B. 

JSC EAGLE LSA MIL-STD-1388-2B Data Exported as MIL-STD-1388-2B Format 

• Exported JSC ISS LSAR data (customized based on MIL-STD-1388-2B). Used ISS 
Columbus data. 
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o 


Export method used was MIL-STD-1388-2B fullfile. Note that this export option 
does allow selection of just one end item, and allows a limited range of LCN's. 

o In this test, a limited LCN set was chosen for just the desired LCN range: start 
LCN of SBAHA1LLL010 and stop LCN of SBAHA1LLL011, for the desired 
"PAYLOAD ETHERNET HUB GATEWAY 2 (PEHG-2) R&R - LAB1D2" on the 
Columbus Module. These LCN's were noted later to be 1 character off of the 
ISS-defined LCN Structure (112223223). 

• Import to TDI EAGLE LSA GEIA-STD-0007 Rev A 

o RESULTS: Could not import into TDI EAGLE GEIA client, since there is not an 
option to import to the older MIL-STD-1388-2B format. This is expected, since 
EAGLE does not convert it. 

• Import to PowerLOG-J as MIL-STD-1388-2B 

o RESULTS: This data did import into PowerLOG-J successfully as MIL-STD-1388- 
2B format, except for some expected duplicate table entries. 

o It was noted that PowerLOG-J has export options for various LSA standard 
formats. For future testing, if other EAGLE data can't transfer, then we could 
test from PowerLOG-J to EAGLE and evaluate if prior errors were due to 
software or standard incompatibilities, or ISS data customization. 

TDI LSA Data GEIA-STD-0007 Export, Import to PowerLOG-J 

• Exported LSA bike data from EAGLE GEIA-STD-0007 as a GEIA fullfile 

• Import to PowerLOG-J as GEIA-STD-0007 

o RESULTS: The data did import, but with some errors. One TM code failed to 
transfer in the XI table, and another TM code had an error. The CJ table didn't 
transfer. The team needs more time to evaluate. We should perform this early 
test again, based on what's been learned since. We think we may be able to 
find the cause of these few errors, but may be able to determine if they're 
caused by the standard, the software, or the data customization. 


DATA EXCHANGE METHODS 

Methods described below are dependent on vendor tools and do not necessarily reflect the 
exchange capabilities of the standards. 

PDM Data Export 

KSC's Windchill enables users to export WTParts (Windchill Technology Parts), WTPart 
Attributes, and Indentured Parts Lists / Product Structures. There are multiple methods 
available to export data. The most direct method is Exporting an Importable Spreadsheet. 
The product structure and Parts data can be exported simultaneously by selecting the Parts 
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and BOM Export Options. Note that attributes are not outputted in the same order from one 
report to another. Null values appear to affect the inclusion/exclusion of an attribute and the 
order of appearance in the generated report. 

PTC's recently released AP239 PLCS Connector (adapter) for Windchill is intended to allow 
data exchanges between Windchill and any tool that is compliant with PLCS DEX1A&D. The 
AP239 adapter is a basic, but extendable import/export converter, which by default covers a 
small part of DEX1A&D only. It has an architecture which is designed to be extended. 
Extension of the converter scope requires further development by the customer or by PTC. 
In its default version, this converter was not ready to use out-of-the-box, and a method of 
enabling this adapter was not developed during the TDI project. 

PLCS Repository Data Import & Export 

Jotne's EXPRESS Data Manager (EDM) is able to support any ISO 10303 application protocol, 
not just AP239. It is a software development kit for users who want to create their own 
converters or even end user applications. 

The PLCS software application used in the TDI project is Jotne's EDMtruePLM. This offers 
import and export of PLCS DEX1A&D data sets from and for any DEX1A&D capable 
application. EDMtruePLM could be extended to manage DEX3 maintenance task information 
in a PLCS compliant way, but such developments were beyond the scope of the initial TDI 
project. 

LSA Data Import 

Note that, unlike MIL-STD-1388-2B, GEIA-STD-0007 does not prescribe how the data must be 
stored. Data cannot be "maintained" in accordance with 0007, but it can be "exchanged" in 
accordance with the standard. EAGLE exchange files for MIL-STD-1388-2B are "fullfi les" and 
for GEIA-STD-0007 are "XML exchange files." 

EAGLE LSAR's GEIA-STD-0007 version can import data of the same standard version. 

EAGLE LSAR's S3000L (DEF STAN 00-60) version can import the same standard version, as well 
as MIL-STD-1388-2B data, for which conversion is attempted. 

PowerLOG-J can import MIL-STD-1388-2B or GEIA-STD-0007 data. It can also import PLCS 
GEIA-STD-0007 Provisioning and Category DEX. 

EAGLE can import external data thru pasting data into tables based on ad hoc SQL queries. 
This allows the user to import data into any desired table. The data must conform to the Data 
Element Definition standards and it must contain all mandatory key fields. The data must also 
conform to any unique key requirements. 

EAGLE also has a Bill of Materials (BOM) import tool to load an indentured parts list and assign 
LCNs to part applications. The BOM import tool receives 6 data fields (see figure below) to 
copy from XLS format and paste from clipboard into EAGLE. 
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If you can get this information out of your existing data you would be able to use this utility 
to calculate your LCNs and populate the following LSAR tables (ignore ZHAEXT, an EAGLE 
table): 

Tables to Fill 

[7]XA - End Item [7]XH-CAGE 
g]XB - LCII 9 HA Parts 
[7] BA - RAM 9 HG - Part Application 

□ Addl Parts TM Data (XI. HB. HG. HI. and HK Data) 

□ ZHAEXT -MMIS I 

There is no automatic import of CAD drawings/models. The graphics can be saved individually 
to the XT document system (GEIA-STD-0007) or to the EAGLE drawing table once the part 
information has been established. 

Raytheon once developed an experimental prototype in the past which was able to read the 
CAD models and drawings with BOM data and attempt to import the data into the EAGLE 
database. They discovered multiple challenges in doing this— most of them believe to stem 
from the business process of the CAD data creators, and not necessarily a technical issue. 
Very few drawings were complete in terms of this supporting data, and they were all missing 
different data elements. In certain companies, for example, the drawing may not necessarily 
be a significant item of record— perhaps instead were the as-built or reports generated from 
their PDM system. Raytheon has developed for some customers an XML export from PDM 
to import into EAGLE, which then linked their PDM to EAGLE through SOAP messaging. They 
would be given a WSDL and then write a custom SOAP client which enables this functionality. 

LSA Data Export 

EAGLE LSAR's GEIA-STD-0007 client can export fullfile data of the same standard version. 

EAGLE LSAR's S3000L (DEF STAN 00-60) client can export fullfile data of the same standard 
version. 
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EAGLE LSAR's MIL-STD-1388-2B client at JSC can export fullfile data of the same standard 
version. The options available also offer to export as GEIA-STD-0007 format. Later, we 
discovered that this export method is no longer supported by Raytheon, and they are 
planning to remove the ability to produce GEIA-STD-0007 data from MIL-STD-1388-2B 
systems. This export outputs data, but does not attempt conversion. 

With all EAGLE-to-EAGLE data conversions, Raytheon recommends the EAGLE XML format, 
which produces one consolidated "kick file" of non-matching data to resolve. 

Since no EAGLE version can import/export PLCS format, the TDI project is developing a 
translator, as described earlier. 

PowerLOG-J can export fullfile data as GEIA-STD-0007. 

S1000D Data Import 

This section will be updated later, in the next version of this white paper. 
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C. Use Cases 

Many industry and government programs, products, and organizations either use or have 
tested standards evaluated by this TDI project. Known cases are described here, as well as 
similar NASA efforts. It should also be noted that the statistics on the S-series websites show 
thousands of hits and downloads, and the U.S. has the most page views by far. 

SIMILAR NASA EFFORTS ON TECHNICAL DATA USAGE 

ISO 10303: NASA-ESA Product Data Exchange (PDE) Workshops have been held annually to 
collaborate on utilization of the ISO 10303 STEP standard for CAD— especially AP203, AP214, 
and AP242. S-series and PLCS AP239 standards have been discussed there, but not pursued 
yet. 

SGML Structured Authoring; Processing Integration: The Work Package Support System 
(WPSS) / Paper-Optional Work Environment (PWE) system used in the 1990's for Shuttle 
ground operations was one of the first NASA projects to attempt integration of various O&S 
data systems: work instructions, logistics inventory, scheduling, etc. Legacy work procedures 
were converted to SGML structured authoring format. A custom Document Type Definition 
(DTD) was developed, including interface integration tags for other systems. SGML was the 
standard for all types of technical manuals used by commercial airlines based on ATA Spec 
100/iSpec 2200. 

SGML Structured Authoring; Processing Integration: The Boeing Delta IV launch sites used 
SGML tools to develop and maintain their procedures. They developed a custom DTD and 
styling process which they used with COTS software (Adobe's Framemaker+SGML, 
Documentum's enterprise content management system, and both COTS and custom 
interface code). All of the assembly, installation, test, and nonconformance procedures for 
the launch sites used these tools and were able to re-use content. A dedicated LSA system 
was not a part of the suite, but many other tools were integrated, including an ERP for parts 
and materials, an MRO for tools, an MES for electronic procedure execution and 
nonconformance processing, and other custom tables for various data needs. Most 
integrations were custom. An XML transformation tool allowed procedures to be executed in 
the MES. Delta conducted multiple assessments of the tools and found that they improved 
procedure creation efficiencies on the order of 2.5-2.8x (compared to a basic MS Word suite 
without sophisticated content management tools). The USAF's Delta IV program was for DoD, 
NASA, and commercial payloads. 

ATA Spec 100/iSpec 2200 (S1000D predecessor): The Shuttle Maintenance Manual (SMM) 
project developed a pilot to implement tech pubs for Shuttle vehicle and ground systems, 
based on the commercial airlines' ATA (now A4A) Spec 100 (now iSpec 2200) standard. This 
fully adopted industry standard was a major contributor to develop S1000D, and the ATA spec 
is now converging on full S1000D compatibility. The SMM efforts continued after the pilot to 
evaluate application to the Constellation program (Ares, Orion, and ground) for S1000D, and 
expanded a vision to evaluate the full S-series and PLCS AP239. 
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Trending TDI Standards: Past efforts made to evaluate trending TDI industry standards 
include industry workgroup participation, vendor discussions and demonstrations, NASA 
research & development (R&D) proposals, and conference papers and presentations. 

Standards and Tools Related to TDI: Evaluation of the ISS technical data environment reveals 
a target-rich opportunity for this project. Separate data sources exist for LSA and technical 
publications (a.k.a. "tech pubs", which include work procedures, technical manuals, and 
training documents). Each data system currently uses technology with potential adaptability 
to modern industry standards evaluated in this project. Each system is customized. These 
systems are setup to be integrated with ISS International Partners/Participants (IP/P), but are 
not 100% integrated. One TDI project team member, Jotne of Norway (also a software 
company with industry standards expertise), was able to support the objective of testing out 
ISS data. The data was related to the NASA/ESA plant experiments and was provided by CIRIS 
and ASTRIUM Defense and Space (former Astrium). 

EAGLE LSAR MIL-STD-1388: In the mid-90's, NASA and the ISS IP/P used SLIC, Leads, AlStar, 
and DILSA LSA software in MIL-STD-1388-1A format. ISS partners Russia, Japan, and Canada 
have always had separate LSA management. In 2000, when NASA changed to use EAGLE LSAR 
in MIL-STD-1388-2B format, they converted NASA and IP/P LSA data to create a consolidated 
ISS logistics maintenance database. Today, NASA and those IP/P's share the database with 
the ability to see live updates. The Canadian Space Agency (CSA) manages their part of LSA 
data directly in NASA's EAGLE LSAR. ESA manages their part of LSA data in their own EAGLE 
LSAR. NASA trained the Japan Aerospace Exploration Agency (JAXA) on EAGLE LSAR for the 
Centrifuge Accommodation Module (CAM), which later on was deleted from the ISS program. 
It is assumed that they still use LSA software compliant with MIL-STD-1388 for their Japanese 
Experiment Module (JEM). The Russian Space Agency (RSA) does not use COTS LSA software. 

EAGLE LSAR MIL-STD-1388: Lockheed-Martin uses EAGLE LSAR (MIL-STD 1388-2B?) for 
NASA's Orion program. 

PowerLOG-J LSA GEIA-STD-0007: NASA MSFC uses PowerLOG-J for the Space Launch System 
(SLS) program. 

Custom LSA & PowerLOG-J: NASA KSC historically has not used an industry standard LSA data 
system, though they were evaluated. The Shuttle program had evaluated the industry 
standard COTS software SLIC, but it was never fully in production. The past CAPSS contract 
had developed a demo of PowerLOG-J, but it also did not continue. The current GSDO/TOSC 
LSA environment uses Logistics Engineering Database (LED), a custom MS Access database. 
They recently evaluated PowerLOG-J. 

XML Tech Pubs, IETM, & S1000D Potential: NASA JSC and MSFC create operation and 
maintenance procedures, technical reference materials. Illustrated Parts Breakdowns (IPB), 
and training materials. Long ago, legacy source data was converted from a Manual Procedure 
Viewer (MPV) used for PDF/paper manuals to develop some Station Operation Data Files 
(SODF) to support on-orbit operations of station hardware and some Payload Operation Data 
Files (PODF) to support science payloads. Some SODFs and PODFs do not have LSA data 
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available as development sources. These are typically created in NASA's Procedure Authoring 
Tool (PAT), which uses XMetal Author Enterprise to author in XML format. Those files are 
then used in the International Procedures Viewer (IPV) as the web-based front end tool to 
view procedures, link to other data, and be an interface for data recording. This is what 
industry and military would call an IETM, and S1000D calls an IETP. Astronauts and ground 
controllers for NASA and ISS IP/P's use IPV on-orbit, in mission control centers, and for ground 
training. XMetal software can also support XML authoring of S1000D. However, NASA's XML 
schema and IPV viewer are highly customized. 

PLCS and Processing Integration: During the Constellation program, an integrated data 
system was developed at KSC using technology and standards which approached the PLCS 
standard. The Collaborative Integrated Processing System (CIPS) used a collection of 
Commercial-Off-the-Shelf (COTS) toolsets spanning the Requirements Management, PDM, 
ERP, MRO, MES, and Quality Control arenas. USA's Attentus™ Integrated Data Management 
system, in conjunction with a data management portal constructed for Ares l-X ground 
processing, provided users with a web-based visual interface that integrated multiple 
application-based datasets into a single logical view of processing operations. This single 
logical view, linked requirements, drawings, graphics, and other related documents, data, and 
content to the paperless Manufacturing Execution System (MES). The MES was used for work 
instructions for vehicle assembly (manufacturing) as well as the whole ground processing 
cycle. The COTS toolsets were all integrated using two software standards: 

• Open Application Group Integration Specification (OAGIS): A common horizontal 
message architecture that provides XML-based schemas for the Business Object 
Documents (BODs) flowing within Enterprise Application integrations. 

• OASIS Web Services Business Process Execution Language (WSBPEL): A business process 
orchestration language enabling users to describe business process activities as Web 
services and define how they are connected to accomplish specific tasks. 

These standards linked requirements management, production control, and configuration 
management across systems, enabling data handoffs from design to manufacturing to 
assembly to operations. This IT system architecture neared an AP239 PLCS approach and was 
a successful test for future programs' needs. 

Other interoperability/integration projects: Other projects began during and after the 
Constellation era at various NASA centers, working on interoperability/integration solutions. 
Some KSC examples were NASA Integrated Model-centric Architecture (NIMA), Digital 
Collaborative Environment (DCE), Information System Strategic Initiative (ISSI), and 
Enterprise Supply Chain System (ESCS). Each had some elements of using MBE, central data 
integration, COTS software, and industry standards. 
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OTHER SPACE INDUSTRY USAGE 



S1000D: TRI-COR Industries adopted Inmedius S1000D Publishing Suite technical 
documentation production software to support NASA, military, commercial IT projects. TRI- 
COR is an Information Technology (IT) support services firm. 

PLCS: Jotne's TruePLM was a European Space Agency (ESA) pilot project that lasted from 
2007-2009, and created the first ISO 10303-239 PLCS compliant applications for space use 
cases as it also implemented selected parts of the European Cooperation on Space 
Standardization (ECSS) requirements. TruePLM is a standards-based data storage server and 
exchange facility long-term data archival capabilities based on PLCS-standardized data. The 
18-month TruePLM program delivered a data management system that is capable of 
integrating product data from various stakeholders in complex space projects. 

S1000D: ITT Exelis uses S1000D for its sustainment of range facilities under the SpaceLift 
Range System (SLRS) for 3 USAF bases, including Patrick Air Force Base (PAFB), Florida's 
Eastern Launch and Test Range, (used by NASA KSC). 

S1000D & MIL-STD 1388-2B: DLR in Germany uses S1000D for Galileo satellite ground 
stations, European Satellite Navigation System Galileo, a joint EU/ESA project. The Galileo 
IETM Tool is a component of the Galileo Logistic Management & Information System and as 
such maintains a MIL-STD 1388-2B compliant interfaces to retrieve supportability data from 
the LSA Data Vault. 

S1000D: ESO uses S1000D for a space telescope in Italy. 

S1000D: Virgin Galactic's SpaceShipTwo and companion White Knight, as well as SpaceX's 
Falcon and Dragon, are supposedly developing S1000D usage, but these were not 100% 
confirmed as of this writing. 


USAGE IN OTHER INDUSTRIES: 

S1000D: Boeing 787 uses S1000D. 

S1000D: Airbus A350 & A380 use S1000D. 

S3000L: A Chinese (COMAC) civilian aircraft project uses S3000L. 

PLCS: The AP239 PLCS Windchill adapter is being tested in a joint effort with Airbus and the 
LOTAR organization. Jotne is involved with them. 

PLCS AP239, AP233, & CAD/CAE: The "Collaborative and Robust Engineering using Simulation 
Capability Enabling Next Design Optimisation" (CRESCENDO) project started in May 2009 and 
ended in October 2012. This project was coordinated by Airbus with a consortium of 59 
partners from 13 countries. The CRESCENDO consortium initiated a step change in the way 
that Modelling and Simulation (M&S) activities are carried out, by multi-disciplinary teams 
working as part of a collaborative enterprise, in order to develop new aeronautical products 
in a more cost and time efficient manner. They developed the foundation for a Behavioural 
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Digital Aircraft (BDA) to use M&S for collaborative product development. The common 
approach was built on AP233 and AP239 standards. They developed DEX specifications, 
providing a mapping from the BDA to AP239 PLCS. This DEX is now included in ASD's 
developing Modelling and Simulation in collaborative System Engineering Context (MOSSEC) 
standard. 

Miscellaneous S1000D Uses: Construction project in Sweden, Field hospital in Germany, IRS 
pilot in the US, Corporate documents in the US, Heavy Kitchen equipment in the US. 


MILITARY USAGE: 

S1000D: S1000D serves nearly every ship/aircraft in the U.S. Navy (as of 2014). The first 
S1000D test case was in 2004. Enterprise-wide solution benefits include reduction in total 
ownership cost. 

PLCS, CAD, & PDM: UTRS used PTC's AP239 PLCS adapter and Jotne's EDMtruePLM PLCS 
repository to develop a way to exchange data from Boeing into the U.S. Army's Windchill 
Product Data Management (PDM). They transfer Technical Data Packages (TDP). They found 
that the adapter was not ready to use out-of-the-box (OOTB), and PTC had to help them fix 
and configure it. Additionally, they had to use Jotne's development toolkit to enable the use 
of the adapter. 

S1000D & PLCS: Jotne North America designed, developed, and made a prototype mapping 
for the definition and configuration of electrical wire harness data from Boeing's proprietary 
Common Electrical Electronic Data System (CEEDS) to the PLCS standard - initially for the B1 
bomber an later the CH47 platform. In the latter contract, the work was further enhanced to 
generate S1000D data modules for ingestion to an S1000D compliant publication system 
(Inmedius Author Pro) that is typically used by the industry. In the process it created a 
Common Source Data Base (CSDB) and relevant Standard Numbering System (SNS) folders 
that are generated by the software as part of the verification process when importing a 
S1000D data set. Final validation was done by visually comparing the data presented with the 
original. A demonstration was provided to a US Army representative at the end of Q1 2014. 

S-Series: According to the NATO Support Agency (NSPA), they currently use S1000D for all 
new projects, and they have recommended that all NATO projects do the same. The book 
TME 2506 (Requirements for NATO Technical Documentation) will be reissued next year to 
reflect the changes that have occurred over the last couple of years. They have produced 
foundation Business Rules for use by NATO nations. These will be published in the new TME 
2506. There is a major drive for all new NATO projects to use the S-series specifications, and 
NSPA is part of that drive. They are currently working on a project that will automate the 
links between our S1000D lETMs and S2000M. The same project will also make full use of 
the available specs in the S-series. NSPA provides NATO's delivering in-service support, 
maintenance and logistics support for weapons systems, as well as operational logistics and 
other services. 
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S1000D, S2000M, & S3000L: The NATO Alliance Ground Surveillance (AGS) Program chose to 
use S1000D, S2000M, and S3000L. Original requirements were to not tailor the standards. 
This was possibly the first S3000L project, so there was a lack of vendors with full support, 
and there was not much experience in application. To fill the gaps, they joined the S3000L 
Working Group and proposed AGS as a case study, and organized workshops with 
experienced companies. As of 2013, the plan was for initial LSA data to be in a format similar 
to MIL-STD-1388-2B (their experience base), but adaptable for full compliance later to 
S3000L. S2000M was easily applied due to NATO experience with it. S1000D Business Rules 
(BR) were being developed. Initial integration was a challenge due to all 3 standards initially 
planning on 3 databases. They claimed that PLCS was not possible to apply at the time, but 
recognized the need for DEX's with a concept like PLCS. As of 2013, they were developing an 
integrated database and backbone system. 

S1000D: Numerous U.S. DoD projects are using or developing S1000D, such as F-35 Joint 
Strike Fighter, ZUMWALT Destroyer, Joint Land Attack Cruise Missile Defense Elevated Netted 
Sensor System (JLENS), Joint Precision Approach and Landing System (JPALS), AMRAAM 
Missile, Rolling Airframe Missile, ALR-67 RWR, Global Hawk, Ciaman, Future Command 
Vehicle, Distributed Ground Systems, Phalanx CIWS 

S1000D: Numerous military agencies from other countries have project which are using or 
developing S1000D, such as Type 45 Destroyer, Astute Submarine, Future Carrier, Future 
Submarine, Airbus A400M, Merlin, Apache, ASTOR, PARS 8X* Armored Vehicle, Scot 
Specialist Vehicle, etc. 

S3000L & PLCS: An S3000L Proof of Concept project for customer-supplier interoperability 
was performed by Engisis with Italian Inter-forces normative for Integrated Logistic Support 
(NIILS). They simulated the exchange of product data (engineering and LSA) between an 
Italian prime contractor and the defense within a subset of the ILS processes. The issues they 
targeted were based on MIL-STD-1388 disadvantages. PLCS DEX1A&D was used for data 
exchange. 

S1000D & LSA: Raytheon delivered a system to the U.S. Army which integrated their LSA data 
and S1000D tech pubs. They used the integrated EAGLE LSAR and EAGLE EPS tools. The tech 
pubs were authored and delivered as an S1000D Interactive Electronic Technical 
Publication/Manual (IETP/IETM) on a militarized handheld viewer. Authoring task times were 
reduced by 30%. 

S1000D: Raytheon delivered a system to a FMS customer in the United Kingdom's MoD which 
integrated LSA data and S1000D tech pubs. They used the integrated EAGLE LSAR and EAGLE 
EPS tools. Reuse of LSA data produced S1000D procedural and Illustrated Parts Breakdown 
(IPB) data modules. That program was able to reuse existing data to produce 80% of their 
IETM. 

S1000D & GEIA-STD-0007: General Atomics worked with the U.S. Navy on the 
Electromagnetic Aircraft Launch System (EMALS) program for aircraft carriers to implement 
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a GEIA-STD-0007 LSA data system that's interoperable with an S1000D tech pubs system. 
They also utilize Creo 3D models from Windchill in the tech pubs. The system is in production. 

S1000D & LSA: LFK-Lenkflugk rpersysteme GmbH (LFK), a German missile system company 
belonging to the European MBDA group, and partner in the Medium Extended Air Defence 
System (MEADS) Program, uses the Inmedius technical publishing system to support the use 
of Logistic Support Analysis Record (LSAR) data to author and manage S1000D procedural 
documentation. 


SOFTWARE COMPLIANT WITH INDUSTRY STANDARDS 

Commercial Off-the-Shelf (COTS) software is available for many of the industry standards in 
the TDI concept. Some are listed in "Life-Cycle Logistics Support Tools, a Survey for NASA" 
from 2012. Customization is usually possible with any of these, but not desirable from the 
standpoint of keeping data and processes standard, per the TDI concept. At the time of this 
project, the following standards were known to have software available: 

S1000D, S2000M, AP239 PLCS, AP203/AP214 CAD, GEIA-STD-0007, and SCORM. 

S3000L has a few use cases, but no COTS software is fully compatible yet with this young 
standard. S4000P was just released this year, so there is no software for it yet, but some is 
being developed already. 

Adapters, or data exchange converters, are also available for various vendor tools: 

• PDM to PLCS 

• 3D CAD to S1000D 

• LSA to S1000D 

Proprietary vendor solutions are also available from various vendors to do many of these and 
other data exchanges or inherent integrations. The TDI concept strives for a plug-n-play, 
vendor-neutral environment, based on industry standards. 
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D. Risk Identification 

To continue with the TDI project, further testing needs to be performed. The additional 
funding received will allow completion of planned testing. Without further testing, the risk of 
continuing this project to a prototype phase could result in unfounded data exchange 
mechanisms or poor results, which could lead to premature decisions to proceed or stop 
pursuit. Mitigation would be to continue testing and update the white paper. 

Trial licenses and support for all TDI software will expire soon (at various intervals). TDI testing 
will not be possible without these. Mitigation would be to pursue extensions or other 
support. Another mitigation would be to pursue different vendors who have software 
compatible with the desired TDI standards, though it would increase time due to setups and 
learning curves. 

TDI project team members may not be available to support further efforts. Each team 
member worked this project part-time. If not available, mitigation could be to find alternate 
personnel, but specific expertise available is limited. External support could be sought to help. 

If the AP239 PLCS Windchill adapter is not tested, or if a user interface is not developed, then 
the PDM to PLCS exchange will likely not be practical due to the amount of effort involved. It 
is recommended to use lnfo*Engine to develop a method of testing AP239 Windchill exports. 
The rough order of magnitude (ROM) estimate is anywhere from 2 to 6 months for the 
lnfo*Engine testing method. Significant time is required to study what is required before a 
more accurate estimate can be obtained. If local TDI team members pursue a working 
solution, additional funding may be needed. Vendor PTC support is only available with 
funding and an indicated scheduling backlog. Also, the 90-day trial of this untested adapter 
will expire in December, and another trial may not be granted without funding. If not funded, 
this known PLCS interoperable functionality cannot be tested. 

The EAGLE LSAR to PLCS simple mapping developed in the TDI project provides a foundation 
for a more complete mapping and future adapter. It is not known yet if it would aid to develop 
a mapping of EAGLE EPS S1000D to PLCS. It is not known if the vendors will develop such 
adapters. The TDI project could encounter a lengthy effort to develop these data exchange 
mappings. The current approach for this mapping relies on the LSA Data Exchange (DEX) 
specification developed by the Army's LOGSA division. LOGSA developers who were involved 
in that effort have stated that the DEX is only about 90% complete. Improving the end result 
from 90% to a point closer to 100% may require a level of familiarity with the GEIA-STD-0007 
and ISO-10303-239/PLCS standard that TDI project personnel will not quickly obtain. 
Mitigations may include requesting reviews of the mapping by LOGSA developers or other 
with more extensive experience with the relevant standards. 

Using the S-series or PLCS may not be allowed in current NASA policies or contracts. Based 
on the Army's LOGSA findings, contracting may be a challenge with the S-series. Mitigation 
may require some NASA policy or contracting adjustments. 
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The AP239 PLCS standard is complex and still not fully mature. It may not gain support for 
widespread industry use. This risk has been accepted by all S-series and GEIA-STD-0007 
committees for years, based on the high need for such interoperability, the lack of other such 
standard options, and the strong foundation of the parent ISO 10303 STEP standard. 

CAD data exchange with non-CAD entities may not be effective if design data is not structured 
in a compatible manner. The draft NASA-HDBK-0009, "Engineering Model Maturity Level 
(EMML): Model Definitions" could help this, but it is not yet released. Mitigation could be to 
develop local guidelines based on the draft and industry evaluations like the S1000D MBETT. 
KSC's CAD community already has some local standards and training in place, as a good place 
to start. 

CAD data converted using neutral formats (STEP, IGES, etc.) can lose some integrity during 
conversions. These risks have been accepted for years in industry. These must be considered 
again when performing CAD data exchanges using the TDI concept to pass data to entities 
outside of the design life cycle phase. Accept this risk, but check integrity. 

Standardization of 3D CAD visualization in S1000D is not fully mature. Mitigation is to rely on 
the S1000D MBETT's interim solutions and planned advancements in 2015. Meanwhile, other 
methods of 3D graphic usage in S1000D are available. 

NASA communities may resist changes such as those described in the TDI concept: 

• Adoption of LSA standards and tools compatible with these standards. 

• Direction to design with data structured in a manner compatible with non-design 
entities. 

• Adoption of S1000D and tools compatible with it. 

• Mitigation could be enabled by education/demonstration of life cycle use as well as 
communication by direct management support. 

General Risks Identified in Industry 

According to AIA, there is a natural cycle of buy-implement-support-buy that companies and 
government agencies seem to follow when deciding to use software applications to help 
improve employee productivity, comply with contracts, or win new business. There is a series 
of events that usually transpires in the life cycle of product development where 
interoperability standards are not considered in the selection or implementation of electronic 
business systems. There are significant business risks to any business or government entity 
associated with not adopting data interoperability standards. These business risks manifest 
themselves in multiple use cases, some of which are detailed here. This is not an exhaustive 
list: 


• Data loss due to application obsolescence. 

• Business process stagnation due to application obsolescence 

• Liability of incorrect manufacture from inconsistent non validated translated data 
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• Intellectual property loss due to application obsolescence and the associated data loss 

• Hardware obsolescence 

• Operational and support costs associated with obsolete applications 
Risk mitigation: 

• Implement standards based interoperability thinking in the business analysis and 
decision-making described above. 

• Develop a data succession plan and an application obsolescence plan 

• Do an exhaustive analysis and evaluation of application functionalities from 
competing application providers prior to acquisition. 

• Choose an application ecosystem and stick with it 

• Avoid any and all application customizations 

• Change or reinvent business processes to accept default application functionality 

• Be careful not to take on too much too fast - implement in gradual steps 

• Stick to a pre-defined plan and avoid scope creep 
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E. Setbacks 

Project start was originally scheduled for April 2014. Various delays in contracting caused a 
delay until August 2014. 

Project requirements limited performance to 90 days for NASA IT Labs deliverables. The TDI 
project attempted to accomplish many tasks with various untested IT configurations and data 
exchanges. Each project team member was only available to provide limited support. With 
these time and resource limitations, software installation and configuration issues hindered 
progress. Most issues appeared to be typical of new systems which would normally be 
resolved quicker with full-time production support. With the typical issues that were mostly 
resolved, forward progress should not cause problems with those IT functionalities. 

Obtaining test data progressed slowly. Raytheon provided the quickest test data— the bike 
data based on industry standards— though it needed some adjustment to work for the 
project. Jotne has good connections with their ESA customer and initiated requests for ESA 
ISS data (EMCS) which resulted in a long process for approvals and data transmission. NASA 
JSC provided quick access and approval to use their ISS LSA data for the Columbus module— 
the closest LSA data known which is partly related to the EMCS data. NASA JSC and MSFC 
work procedures related to the ESA ISS data set were pursued. Contacts and permissions 
were obtained after a long process, shortly before TDI project testing was being finished for 
the final paper and presentation. 

One expected obstacle was the lack of existing adapters in the industry. The ideal concept 
being evaluated in this TDI project is where each vendor has one adapter to plug their tool 
into a PLCS-compliant tool. One adapter exists for the Windchill PDM to exchange data with 
EDMtruePLM. No adapter exists for EAGLE LSAR or EAGLE EPS to exchange with 
EDMtruePLM. This was assumed upon project start. This obstacle was magnified due to lack 
of resources to perform full evaluation of mapping/conversion needs. Many vendor tools 
support various emerging standards, but adapters have not been developed yet for most of 
them to the PLCS standard. 

The AP239 PLCS adapter was not ready out-of-the-box to use for CAD data exchanges. The 
adapter was installed in Windchill, but there is no user interface. PTC was not funded in this 
project and therefore was not able to support other than suggesting that we develop our own 
import/export interface, or else use PTC's lnfo*Engine to develop a way to test functionality, 
same as they do in their R&D and quality departments. The TDI project did not have resources 
to perform these potentially extensive efforts. The rough order of magnitude (ROM) estimate 
is anywhere from 2 to 6 months to develop an lnfo*Engine testing method. 

The PLCS repository client performs DEX1 exchanges out-of-the-box, but requires 
development for DEX3 functionality. The software has the capacity to handle DEX3 data, but 
developer software is required, until a planned future update enables this for user clients. 

ISS LSA data exchanges from JSC's EAGLE LSAR were not clean. This was somewhat expected, 
since the system is customized and based on the older standard MIL-STD-1388-2B. Also, it's 
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suspected that software limitations restricted desired results. Exports to the desired GEIA- 
STD-0007 format could not be performed on the desired small subset of data, but rather the 
entire ISS data set had to be exported. When GEIA-STD-0007 or MIL-STD-1388-2B exports 
were then imported into TDI's EAGLE LSAR GEIA-STD-0007 version, a special character in the 
end item had to be removed before imports worked. Other errors occurred during import 
attempts to both TDI's EAGLE versions and to PowerLOG-J. More time was needed for 
thorough evaluation of data exchange integrity. 


28 


F. Successes 


The TDI project has accomplished some validation testing for this industry concept which has 
not been attempted much in the industry. The concept of a PLCS central repository with the 
IPS/ILS elements all exchanging data through that one interface has been presented at many 
industry and government conferences globally. This project broke some of that ground which 
was untested, or rarely known/tested— steps toward further validating that concept. Though 
not all interfaces were able to exchange data as intended, lessons were learned, and a path 
forward is laid out to enable desired exchanges. 

The most significant accomplishment in the ideal TDI concept of exchanging data through 
PLCS is the mapping of LSA data from EAGLE LSAR to PLCS format. The TDI team created a 
partial data conversion map, due to lack of an adapter available for EAGLE in PLCS format. 
Though the TDI project will target this for import into Jotne's EDMtruePLM PLCS repository, 
the conversion would be usable for any PLCS compliant tool. The translator is about 20% 
complete. Portions of the LSA-PLCS translator design implemented include: 

• A module for text encoding of PLCS output data. 

• Hand-generated versions of several modules for PLCS entities and attributes, which 
will eventually be auto-generated from the EXPRESS schemas. 

• Partially-generated modules for the DEXlib templates, which will be fully automated 
with the inclusion of a parser for the Instantiation Path syntax. 
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<logist ics_support_anal ys is_u nt rol_number_no ,nclature>BICYCLE ASSEMBLY</logist ics_support_anal ys is 
<logist ics_support_anal ys is_coi. ,, *ol_number_t yp >P</logist icr .support _anal ys is_cont rol_number_t ype> 


\ \ r 


#646= PARK ’/IGNORE’ , ’/IGNOkF’ , V] GNORE’ ); 

#645= PR0DUCT_CATEG0RY($, ’part’ $); 

#644= PRODUCT_CATEGORY_ASSIGNME,.y ( ’645, ( /646) ) ; 

#647= IDENTIFICATION_ASSIGNMENT ( ’ N/ SATES ’ , ’/IGNORE’ , ’/IGNORE’ ,(#646)) 
#676= PART_VERSI0N( ’/IGNORE’ , ’/IGNO ?E’ ,#>46); 

#679= IDENTIFICATION_ASSIGNMENT ( ’1’ , ’/IG !0RE’ , ’/IGNORE’ , (#678)); 

#701= IDENTIFICATION_ASSIGNMENT ( ’BIKE’ , /IGNORE’ , ’/IGNORE’ ,(#678)); 
#709= DOCUMENK ’/IGNORE’ , ’/IGNORE’ , ’BICYCLE ASSEMBLY’); 

#715= DOCUMENT_ASSIGNMENT (#709, #678. ’/IGNORE’ ); 


Other testing accomplishments: 

• The PLCS repository was populated with several test data sets. Data was entered by 
DEX1 import and manual entry. 

• The PLCS repository exported data as DEX1, and this was used to evaluate for 
development of a conversion map with EAGLE LSAR. 

• ISS EAGLE LSA data was exported, then imported to PowerLog-J successfully. 
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• Windchill CAD product structures were exported to exchange BOM data, and they 
were imported into EAGLE LSAR using the vendor BOM import tool. One of the largest, 
most complex KSC CAD product structures was successful in this, as well as the 
industry standard bike sample data set. 

The AP239 PLCS Windchill adapter was verified by PTC as installed correctly. It was not 
functional, but an industry project was discovered that recently went into production which 
utilized this adapter with a PLCS repository. This evidence demonstrates a PLCS-centered 
system that works with Windchill, the PLCS adapter, and TruePLM. An estimate to perform 
the testing gives hope of reasonable performance expected. 

Much research was accomplished to better understand the suite of related ILS/IPS standards 
and how they can best exchange data. Updates to and position papers on many of these 
standards surfaced between TDI project submission and the writing of this paper. These shed 
a positive light that the global standards communities involved are committed to resolving 
interoperability challenges. 

Various data sets were obtained for the TDI project, freely providing a healthy foundation for 
further testing. Real ISS data was obtained with export control approval from multiple NASA 
and ESA sources. Sample data used by the industry is also lined up for simple, generic testing. 
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G. Recommendation 

Results so far point to a positive direction for the TDI standards. Standards-based, vendor- 
neutral interoperability between PDM, LSA, and Tech Pubs data appears to be available or 
developing within a year or two. Further testing could validate this. 

In the short term, it is recommended to continue with the testing that is able to be 
accomplished. Updated results should be considered to incorporate into revision 1.1 of this 
white paper. More time is needed for thorough evaluation of data exchange integrity. Desired 
testing which was not completed during the project so far was: 

• JSC ISS EAGLE LSAR export as XML, import to TDI EAGLE GEIA client as XML. 

• JSC ISS EAGLE LSAR export as 2B, import to PowerLOG-J, then export as GEIA, then 
import to TDI EAGLE GEIA client as GEIA. 

• JSC ISS EAGLE LSAR export as 2B, import to TDI EAGLE S3000L (DEF STAN 00-60) client 
as 2B. 

• Export TruePLM PLCS data as DEX1, attempt import to PowerLOG-J. 

• Use JSC ISS data imported into TDI EAGLE LSAR (both GEIA & S3000L versions) to 
produce EAGLE EPS S1000D data and publish as an IETP. Compare with NASA's IPV. 

• Evaluate what it would take for NASA IPV's XML version of SODF/PODF procedures to 
convert/import into EAGLE EPS S1000D. 

Another test we recommend is to request for JSC's Orion EAGLE LSA and MSFC's SLS 
PowerLOG-J LSA to test data exchanges with each other, and then with other TDI standards. 

For the LSA-PLCS translator development, detailed designs and project plans are needed for 
remaining components, with an aim of obtaining support for additional time and resources 
to complete the implementation, fully leveraging existing mappings encoded in the LSA DEX. 
Pending completion of these plans, an estimated rough order of magnitude (ROM) for 
completion of translator implementation is 3 months of full-time development effort. 
Coverage at this stage would include approximately 90% of the DEX1 (product breakdown 
structure) subset of the PLCS standard. Analysis of translator performance and coverage 
would be required to determine additional effort required for greater coverage of the full 
PLCS standard. 

For the long-term, it is recommended to carry results forward to the next level, by testing a 
networked integration of this setup, by addingtests of additional functionality, and by adding 
data sets from more space products/systems. One of the additions which should be tested is 
an evaluation of the potential of the TDI standards, tools, and data exchange methods to 
exchange data or integrate with Manufacturing Execution Systems (MES) or similar work 
execution systems. KSC currently uses Solumina and Maximo software for this. Past research 
indicated an S1000D usage with Maximo. Such potential should be evaluated to determine 
the value related to TDI concepts. Also, pursue development of a way to test CAD data exports 


31 


using PTC's AP239 PLCS adapter. Evaluate if this could be done with local KSC personnel or if 
funded vendor support would be required. Additional funding will be needed to perform 
these recommended long-term actions. 

Upon evaluation of test results described above, if results show good potential, then a full 
integration pilot should be pursued. 


G-l Feasibility 

The TDI concept appears to be technically feasible, but more testing and evaluation 
needs to be performed to determine how ready the COTS tools and industry standards 
are. For S1000D and GEIA-STD-0007, those standards are more mature and have COTS 
software ready for individual or integrated implementations without customization 
required. Others like PLCS (COTS software available) and S3000L, and interoperability 
solutions between any TDI standard, can be implemented, but the levels of 
customization or development needed are not clearly understood. Further study will 
continue to evaluate this better. S2000M was not evaluated, but COTS software is 
available, and it's used by many in NATO and Europe. SCORM was not evaluated, but 
numerous COTS software and use cases exist. 

Initial development of the LSA-to-PLCS translator indicates that the basic approach is 
sound, with additional work required to further develop highly-automated generation 
of the translation based on existing mappings encoded in PLCS DEX form. 

Financial feasibility has not been analyzed in detail at this time. Further study would 
provide this assessment. Industry use cases show cost and time savings. Initial 
investment has been noted to be higher, with much greater long-term gains later. 

Since many NASA programs/projects are currently in development, now is the best 
opportunity to realize technical and financial feasibility. For NASA systems which don't 
adopt the TDI concept now, savings would be less and later. 


G-2Value 

True interoperability of life cycle technical data which is vendor-neutral, non- 
customized, and based on standards has not been possible until recently. The TDI 
concept is designed to lower the LCC with early design influence on the full life cycle, 
continual interaction of technical data across the life cycle, utilization of industry 
standards and COTS software instead of custom data systems, and efficiency, quality, 
and safety gains available within each of the modern standards and software. 

Use of the TDI concept standards have shown time and cost savings in the use cases 
described earlier. The best gains of course are for new projects, and some programs 


32 


have found benefit in converting legacy systems. Access to specific cost savings data has 
been pursued, but is generally proprietary. 

Efficient IT systems, and intelligent organization of the content which IT manages, can 
save significant time and therefore cost with NASA's high volume of technical data. Too 
much time is wasted due to lack of finding or reusing data. According to "The Hidden 
Costs of Information Work," a 2006 IDC study of information/knowledge workers, it 
revealed that: 

• They spend 48 percent of time searching (9.5 hrs/wk) & analyzing (9.6 hrs/wk) 
information. 

• They waste 3.5 hrs/wk in unproductive searches (info not found). 

• They waste 3 hrs/wk recreating content that already exists. 

• Not finding the information needed costs an organization employing 1,000 
knowledge workers about US$5.3 million per year. 

The PLCS and S-series standards, and GEIA-STD-0007, emphasize data reuse and provide 
efficient mechanisms to make data easier to find and utilize. 

Model-Based Enterprise (MBE) is the modern trend of designing data systems to allow 
direct access to 3D models and related data. Much of design data can be reused for 
technical manuals, LSA, etc., saving hours of research and re-creation time. Mere PDFs 
of 2D drawings doesn't provide such savings, and they're not always easily found when 
searched for. 

An example of the value of using S1000D is described well by one customer of a U.S. 
military product who listed the following realized cost benefits: 

Decreased Lifecycle Support Costs 

• Streamlined change management and multi-format delivery process 

• Increased revision efficiency 

• More time for data review leads to reduced data errors 

• Decreased Technical Orders (TOs) 

• Contracting Data Modules (DMs), not publications 

• Quality i" Costs 
ROI Factors 

• Average cost savings % using S1000D for the program - "High Teens"% 

• Data Reuse - achieved up to 70% 

• Realized up to 50% cost savings producing manuals 

• Realized opportunities to manage common data - 10% same in all books 

• Realized added benefits of Applicability 

• Reduces numbers of books authored, edited, maintained, but retain ability 
to deliver all configurations required 

• Increased output consistency 

In one white paper on S1000D, they summarize some "real-life ROI cases": 
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• 63% cost reduction by an aerospace engine manufacturer that simultaneously 
increased the number of parts catalogs from 81 to 132, while reducing the 
number of authors from 18 to 3. 

• 20% productivity gain by aircraft mechanics by providing customized job cards 
(for example, an engine removal procedure was reduced from 100 pages to 30 
pages, thus making 200 mechanics more efficient!). 

• 48% cost reduction (after 9 months) in the production of technical 
documentation using S1000D. 

• 20%+ cost reduction in the production of computer-based training by using 
S1000D and SCORM. 

That same white paper also discussed the value of availability, using an example 
scenario of using LSA data and S1000D tech pubs data. An energy company performed 
a study to determine how the availability of correct and intelligent technical information 
would contribute to the increased availability of their energy facilities. They found that 
facility availability was impacted by: 

• Mean Time Between Failure (MTBF) - this is also known as "Reliability". 

• Mean Time To Repair (MTTR) - this is also known as "Maintainability". 

• Mean Waiting Time (MWT) - this is also known as "Supportability". 

Availability was calculated as a function of MTBF, MWT and MTTR. The energy company 
determined the value of 1% availability was: 

• 1% availability of a windmill is worth 15,000 EUR per windmill per year 

• 1% availability of a nuclear reactor is worth 5 million EUR per year 

In the projected calculations using LSA data linked with S1000D data improved from 90% 
to 94% availability. In addition to savings using S1000D itself, their experience displays 
the ability to save 20% in transforming LSA data to S1000D DM's. 

The white paper went on to estimate a scenario where, with adoption of S1000D, 
assuming an investment of $500,000 in technology, $20,000 in implementation services 
and $100,000 in software maintenance, the Net Present Value and Internal Rate of 
Return over 3 years is highly favorable. They show a break-even point after about 1.5 
years. 

ILS/IPS has a large impact on LCC. Handling of technical data is a significant part of that. 
Dr. Kevin Watson of NASA Headquarters Logistics said in a 2010 AIAA paper: 

" Neglecting ILS or implementing poor ILS decisions invariably have adverse effects 
on the life cycle cost of the resultant system. ..NASA is placing renewed emphasis 
on the importance of considering the support concept for systems (e.g., a 
spacecraft) at the earliest stages of a program or project... For NASA space flight 
projects, the NASA life cycle phases of formulation and implementation are divided 
into incremental pieces. ..Of critical importance is the acquisition logistics content 
(often referred to as supportability planning), which should focus on the tasks that 
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examine all elements of a proposed system or product to determine the logistics 
support required to keep the system/product/asset usable for its intended purpose 
and life cycle, and to ensure that the design process results in a system that can be 
supported at a reasonable cost. With a significant percentage of product life cycle 
costs occurring in the sustainment phase of the life cycle, applying acquisition 
logistics in the design phase is the best way to reduce the life cycle costs." 

Initial assessment is that the integrated standards of the TDI concept would likely 
provide significant value to NASA centers. Benefits are available with adoption of each 
individual standard, but benefits would be greatly magnified upon adoption of each part 
of the integrated suite of standards. 
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H. Appendix 

H-l Lessons Learned 

LESSONS LEARNED FROM TDI PROJECT 

Lessons were learned on how to plan and acquire all that's needed to perform testing 
like the TDI project. These "logistics" took much of the project's time and effort, even 
before the start of the 90-day project period of performance. It was discovered that the 
only mechanism for ESC contractors to perform work such as the TDI project is a Task 
Order (new or in-scope addition). This required a long lead time and used some of the 
allotted funding. Some additional funding was obtained in the beginning, intended to 
help accomplish TDI objectives in that time, as well as allow budget to continue testing 
or add features. Mechanisms are in place to continue testing for a short while longer. 

If future efforts are funded, plans should include hours and travel to attend appropriate 
industry conferences or working group meetings. Time would be needed to propose 
papers and/or make presentations. An additional deliverable for the TDI project is to 
submit results to industry forums. 

One lesson learned from testing was to not perform exports from an EAGLE LSAR MIL- 
STD-1388-2B client in GEIA-STD-0007 format, since this is no longer supported by the 
vendor. 

LESSONS LEARNED FROM NASA 

Disparate technical data increases safety risks from poorly integrated elements, as 
outlined in the Columbia Accident Investigation Board (CAIB) report. 

An SLS Program LSA report says that initial LSA development should be provided in 
conjunction with the design effort. After initial development, an operations contractor 
should then be brought in to lend insight and past operational experience with similar 
systems to further develop LSAs. TDI comments: LSA is sometimes ignored during the 
O&S phase, as it was for Shuttle. A formal LSA data system should be organized and 
planned for continual use during the whole life cycle. ISS currently does this. 

LESSONS LEARNED FROM DOD/INDUSTRY INTEROPERABILITY PROJECTS (from AIA) 

There have been a few examples in the media recently that illustrate the hidden costs 
that can surface when interoperability is not considered as a key element of an 
application architecture or implementation. 

• A European aircraft manufacturer announced an additional 5 billion euro cost 
increase in a product launch from design flaws due to lack of interoperability 
between different CAD systems. 
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• In the March 1999 NIST study of the interoperability cost analysis of the US 
automotive supply chain estimated that imperfect interoperability imposes a $1 
billion annual cost on the members of the US automotive supply chain. 

• Respondents to a 2008 mold design and manufacturing industry survey were 
asked if customer unique CAD requirements added significantly to their cost of 
doing business. Of those responding, more than a quarter estimated that those 
requirements add 20 percent or more to the cost of doing business. 


H-2 Benchmarking 

No benchmarking was performed. 


H-3 Description of TDI Industry Standards 

This section will describe the industry standards evaluated in the TDI project. It 
encompasses research relevant to project evaluations, and it is a reference for readers 
who may not be familiar with some details or current developments with these 
emerging standards. 

Various organizations produce standards and specifications. The space industry has a 
few, such as NASA, European Cooperation for Space Standardization (ECSS), 
Consultative Committee for Space Data Systems (CCSDS), etc. There are standards 
organizations that are not exclusive to the space industry which include some standards 
applicable to space. Many of the almost 300 Technical Committee (TC) areas in the 
International Organization for Standardization (ISO) apply to aerospace. Each Technical 
Committee is divided into Subcommittees (SC) for major functional areas, and the 
subcommittees are further parsed into Working Groups (WG) with very specific focus. 

Standardization of space hardware design is important and increasingly needed. 
However, with all Standards Development Organizations (SDO), ground processing is 
one of the areas least addressed. By ground processing, that could include 
assembly/integration, test and checkout, launch operations, maintenance and repair, 
supporting infrastructure systems, etc. Any of these could apply to a launch vehicle, 
payload/cargo, space station/habitat, launch pad, processing facility, or support 
equipment. "Ground processing" is typically covered by what the industry calls 
Integrated Logistics Support (ILS) or Integrated Product Support (IPS). The Evolved 
Expendable Launch Vehicle (EELV) requirements include a call to standardize 
infrastructure and processes in addition to design. The EELV requirements document 
stated in 1998 that one of the reasons that the Expendable Launch Vehicle (ELV) launch 
systems at the time were cost ineffective was due to lack of standardization of facilities, 
processes, vehicles, procedures, and supporting infrastructure, making each mission a 
unique event. 
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Many ILS/IPS entities rely heavily on technical data. To create, use, and manage 
technical data efficiently requires Information Technology (IT). Many IT industry 
standards exist. Some IT applications utilize these standards efficiently, and some are 
too custom to be efficient. It has been rare to find sets of industry standards that are 
unified between IPS and IT, or find standards which define both needs together well. 
The suite of standards being evaluated in the TDI project provide not only unified 
definition of both IPS and IT for each IPS function, but they are working together to 
integrate across all IPS entities and to cross-over to design entities. 

Emerging Standards Evaluated in TDI Industry Concept 

New and reworked industry and military standards for Integrated Product/Logistics 
Support (IPS/I LS) or technical data have been released in recent years. More are in 
development. Joint agreements and efforts with international entities are in place, and 
integrated councils and work groups are working toward goals of interoperability across 
the whole life cycle. The emerging industry standards which are related to each other in 
the industry concept are: 

• ISO 10303-239 Product Life Cycle Support (PLCS), a.k.a. AP239. 

• S-series Suite of Specifications 

o Jointly managed by Europe's Aerospace and Defence Industries 
Association (ASD) and America's Aerospace Industries Association, (AIA). 
S1000D management also includes Airlines for America (A4A), formerly 
the Air Transport Association (ATA). 

o S1000D: International Specification for Technical Publications Utilizing a 
Common Source Database (CSDB), Issue 4.1, Dec 2012. 

o S2000M: International Specification for Materiel Management, Issue 
5.0, May 2012. 

o S3000L: International Procedure Specification for Logistic Support 

Analysis (LSA), Issue 1.1, Jul 2014. 

o S4000P: (formerly S4000M), International Specification for Developing 
and Continuously Improving Preventive Maintenance, Issue 1.0, May 
2014. 

o S5000F: International Specification for Operational and Maintenance 
Data Feedback, Issue 0.2, Jun 2014. 

o S6000T: International Procedure Specification for Training/TNA (draft in 
work). 

• INDUSTRY LSA managed by SAE (overlap S3000L) 

o GEIA-STD-0007: Logistics Product Data, Rev B, May 2013. 
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o GEIA-HB-0007: Logistics Product Data Handbook, Rev B, Feb 2014. 

• SCORM (Sharable Content Object Reference Model): A collection of standards 
for e-learning. SCORM 2004 4th Edition was released in 2009. It's compatible 
with S1000D. 

The S-series ILS/IPS standards have their own councils and working groups. The ASD/AIA 
ILS Specification Council was formed when the need was identified for an "umbrella" 
specification to ensure the compatibility and commonality of ILS processes among the 
suite of ILS specifications. In 2011, the decision was made to develop, publicize and 
maintain an ILS guide, named SXOOOi, so as to provide a compatible and common ILS 
process to be used in the other ILS specifications. SXOOOi will also define the mechanisms 
that will be used to ensure that the suite of ILS specifications is both integrated and 
interoperable. 

The ASD/AIA Data Model and Exchange Working Group (DMEWG) was formed under 
the ILS Specification Council in 2011. The DMEWG coordinates the data modeling 
activities that are performed within the respective ILS Specification Steering Councils 
and Workgroups so as to harmonize and consolidate data requirements into one 
coherent data model. The DMEWG is also responsible for the governance, review and 
publication of Aerospace and Defense Data Exchange Specifications (A&D DEXs), using 
ISO 10303-239 Product Life Cycle Support (PLCS). 

The AP239 PLCS standard is the link between technical data for ILS/IPS entities and 
design entities. This provides data exchange mechanisms across the entire life cycle of 
a product/program. The ISO TC collaborates with the S-series and similar standards for 
interoperability. Global military standards have been very interested in AP239, and 
some of those standards have been getting modified to align with PLCS. 

What's "Emerging" about Technical Data Standards? 

When the TDI project was proposed in December 2013, the suite of TDI standards was 
promising. Since then, various standards have either had initial release, a significant 
release update, or industry positions taken on their adoption. These standards have 
been developing for years, but maturity and adoption has been only recent. Maturity 
appears to be taking a fast turn at this time 

The figure below shows the large number of releases of the S-series suite of standards 
(specifications) due to occur in 2014 and 2015. This is due to planned harmonization 
coming to fruition. 
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The U.S. DoD went through acquisition reform in 2009. In 2011, they updated ILS 
standards, handbooks, and directives, renaming classic ILS terminology to Integrated 
Product Support (IPS). The set of changes includes: 

• 10 ILS elements changed to 12 IPS elements. (These include all technical data in 
the TDI industry concept and their corresponding functional entities.) 

• Performance Based Logistics (PBL) changed to Performance Based Life Cycle 
Product Support (PBL). 

• Performance Based Logistics: A Program Manager's Product Support Guide ("The 
PBL Guide") changed to Product Support Management (PSM) Guidebook. 

• ILS Plan changed to Life Cycle Sustainment Plan (LCSP). 

• PLCS and the S-series references were added to various IPS handbooks, policies, 
and training. 

The U.S. military's LSA standard was developed in 1984 and has been used globally by 
various countries - even to this day. As seen in the figure below, LSA standards have 
been through various changes. S3000L is the recent S-series answer to part of an LSA 
data system's needs. The U.S. DoD adopted an industry standard, GEIA-STD-0007. The 


40 






U.K. developed Def Stan 00-60. Each of these active LSA standards have been working 
their way toward compatibility with AP239 PLCS. 


The ISO 10303-239 PLCS standard came from a joint industry and government initiative 
to accelerate development of new standards for product support information (basically 
IPS or ILS). This international project began in 1999, and the initial revision release was 
in 2005. The AP239 second edition was released in 2012. 

Convergence of Standards toward Interoperability 

How does one know that these recent standards are proven and worth adopting? In 
addition to a growing set of global users, there is a history to their development. 

The Computer Aided Logistics Support (CALS) initiative was begun by the U.S. Defense 
Department in 1985. Later, NATO also took up CALS. Its purpose is and was to facilitate 
the integration of digital information for weapons system acquisition, design, 
manufacture and support functions. CALS later changed to mean "Continuous 
Acquisition Lifecycle Support." An LSAR (Logistics Support Analysis Record) database 
standard MIL-STD-1388-2 was formed in relation to CALS, which the FAA also adopted. 
CALS required the OEM to create LSAR data and to include it with Interactive Electronic 
Technical Manual (lETMs), Support Equipment Recommendation Data, and Training 
Data. lETMs were based on MIL-M-87268 and MIL-D-87269, with SGML text authoring 
and CCITT Group 4 and CGM graphics standards. 

Meanwhile, in Europe, the AECMA aerospace organization developed their own related 
standards, 1000D for lETMs, and 2000M for Illustrated Parts Catalogs (IPC) and 
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Provisioning. The NATO CALS model was based on 3 standards: MIL-STD-1388-2B, 
1000D, and 2000M. 

AECMA has since been renamed ASD (AeroSpace and Defence Industries Association of 
Europe), and the two specifications are called S1000D and S2000M. These standards 
have transitioned their data exchange standard from SGML to XML. The U.K. has since 
developed DEFSTAN 00-600 for ILS, GEIA's LSA standard GEIA-STD-0007 replaced U.S. 
military standards, and ASD has since developed S3000L and S4000P for LSA. 

PLCS AP239 is the interoperable link which connects the O&S data environment with the 
design data environment. It's parent ISO 10303 is managed by ISO Technical Committee 
(TC) 184, but AP239's working group collaborates with the ILS/IPS community of 
standards. The figure below shows PLCS relationships to standards and programs which 
contributed to AP239 during development from 1999-2004. It represents a view of the 
trends where industry and government standards are converging toward a common 
interoperable model. 



The most recent status of adoption and development of all related standards being 
tracked by ASD is shown in the figure below, from October 2014. 
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The most recent status of adoption and development of all related standards being 
tracked by AIA is shown in the figure below, from 2013. 
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S-Series Data Exchange Standards 

Interoperability and commonality between each of the S-series standards has been in 
development by the ASD/AIA ILS Spec Council. The specifications to harmonize these 
standards are coming to fruition in 2014 and 2015, listed below: 

• SXOOOi: International guide for the use of the S-Series Integrated Logistics 
Support (ILS) specifications (draft in work) 

• SX001G: Glossary, Issue 1.0, Dec 2014 

• SX002D: Common Data Model, Issue 1.0, Dec 2014 

• SX003x: Compatibility Matrix for the S-Series ILS Specifications (draft in work) 

• SX004G: UML model readers guidance (draft in work) 

• S1003X: S1000D to S3000L Interchange Specification, Issue 1.0, Mar 2011 

o S1003X provides a cross reference matrix of S3000L to S1000D data 
element to facilitate the exchange of task information. An initial draft 
matrix of data elements between GEIA-STD-0007 and S1000D has been 
drafted but not published. 

Technical Publications (Procedures & Manuals) 

The general term Technical Publications (a.k.a. "Tech Pubs") is used in industry for 
technical reference manuals, work instructions, and training manuals. The term 
Interactive Electronic Technical Publication (IETP) is the most advanced form of Tech 
Pubs. Before S1000D, they were called Interactive Electronic Technical Manuals (IETM). 
Some identified them with class numbers based on complexity. The predecessor to 
lETM's is various forms of paper and electronic Tech Pubs, some which were governed 
by industry specifications or standards, and many which were governed by none or only 
internal policies. 

S1000D International Specification for Technical Publications Utilizing a Common 
Source Database (CSDB) 

S1000D was produced to establish standards for the documentation of any civil or 
military vehicle or equipment. It is based on international standards such as SGML/XML 
and CGM for production and use of electronic documentation. In addition, it defines a 
Common Source Data Base (CSDB) to provide source information for compilation of the 
publications and for use in electronic logistics information systems to deliver modules 
of information direct to the user. S1000D has also been linked to the PLCS development, 
which enables the compilation of technical documentation direct from the current 
product structure, and to SCORM, for training materials. 

The key business driver is to reduce the cost and complexity of technical documentation 
by providing a modular structure with components that can be reused for different 
product versions. The use of a common structure also permits the use of generic 
viewing tools which are not specific to a particular product. Adoption of S1000D 
provides a common structure for technical documentation which is interoperable across 
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products and customers. It has also been proved to make the preparation of technical 
documentation faster and less expensive, and simplifies translation into other 
languages. 

The figure below shows how reusable Data Modules (DM) can be compiled into various 
forms of tech pubs. 


Create / Import Once 



Data Modules 



DM5 


A Data Module Code (DMC) represents each DM, structured with levels of intelligence. 
The Standard Numbering System (SNS) in the beginning of the DMC is the hardware- or 
system-based product structure. In the figure below, the light grey X's are optional, for 
expansion purposes. NATO maintains the Ml for those who register. 


Hardware / System Identification 


Ml: Model 
Identification 


Product/project 

Examples: 

• 1F22B=F-22 B 

• DC9=Boe. DC-9 

• Mi38=Mil Mi-38 
Helicop. (Russia) 

• JJ=Saab GSE 

• AA=Apache 
missile (France) 

•PW1000G=P&W 


engine series 
• GalULS=Galileo 
uplink station 


SDC: System 

Difference 

Code 


I Id. alt. versions of 
sys’s in SNS 



SNS: Standard 

Numbering 

System 


Sys-Subsy-Unit 
• Initial XX-X is set 
by MICC 


(Opt.) MICC: 
Materiel Item 
Cateaorv Code 


SNS code set: 

A -Generic 
B -Supt/train eqpt. 
C -Ordnance 
D -General comm. 
E -Air vehicle 
F -Missile 
G -Surface vehicle 
H -Sea vehicle 


xxxxxxx 

-xxxx-xxx-xx- 


ir 


I Information Type \ / Learn Type \ 


DC/DCV: 

Disassembly 

Code/Variant 


Further 

breakdown for 
maintenance 

DC=2 char. 


DCV=1-3 char. 


IC/ICV: 

Information 

Code/Variant 


Type of Info: 

IC=3 char. 
Oxx-Function, 
data, descrip. 

1 xx-Operation 
2xx-Servicing 
3xx-Exam / test 
4xx-Fault isolate 
5xx-Disconnect / 
remove 
6xx-Repair / 
make 

7xx-Assy / instl 

8xx-Storage 

9xx-Misc 

ICV =1 char. 


ILC: Item 
Location Code 


Situation/place 
applicable to the 
info 

A -Installed 
B -Installed on a 
removed 
major assy 
C -On bench 
D -Combo of A, 
B, & C 

T -Training info 
only if no LC 
Z -Generic 


(Opt .) LC/LEC: 
Learn / Leam 
Event Code 


LC=3 char. 


Hxx -Human 
performance 
technology 
Txx -Training 


LEC=1 char. 

A -Learn plan 
B -Learn 
overview 
C -Leam content 
D -Leam 
summary 
E -Learn 

assessment 


-XXX 


-xxxx-x -xxxx 
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S1000D was designed for air, land, and sea vehicles, as well as support equipment. 
There are predefined SNS sets for these product/project types in the standard, and 
various others have been added as well. They are not mandatory, but they represent 
industry best practices. There are no SNS sets for the space industry, but S1000D could 
easily be adapted to space vehicles and facilities, too. See the potential example usage 
in the figure below. Note how commonality can be achieved across types of data sets. 


Ml: Model Identification 


Product/project 

Potential Examples: 

• AtlasV5=Atlas V 500 Series 

• X37B=X-37B Orbital Test 
Vehicle (OTV) 

•CST100=CST-100 Capsule 
•RD180=RD-180 Engine 
•SLS=SpaceLaunchSys 
•ISS=lnt'l Space Station 




SDC: System 

Difference 

Code 


Id. alt. versions 
of sys’s in SNS 


(Opt.) MICC: 
Materiel Item 
Category Code 


SNS code set: 

A -Generic 
B -Supt/train eqpt. 
E -Aerosp* vehicle 
F -Missile/rocket* 

H -Sea vehicle 
S -Space station* 



SNS: Standard 
Numbering System 


Sys-Subsy-Unit 
• Initial XX-X is set by 
MICC 

24 Vehicle Elec. Power 
-30 DC Generation 
74 Engine Ignition 
-10 Elec. Power Supply 


DC/DCV: 

Disassembly 

Code/Variant 



ATLASV500XXXXX ^501X -F24-30-00XX -000XX ' 
X37BXXXXXXXXXX -OTV1-E24-30-00XX -000XX 
RD1 80XXXXXXXXX -0XXX-F74-10-00XX -000XX 
SLSXXXXXXXXXXX -001X -E24-30-00XX -000XX 
ISSXXXXXXXXXXX -SCXX-S 24-30-00XX -000XX 


SCORM (Sharable Content Object Reference Model) 

SCORM began in 1997. It is a collection and harmonization of specifications and 
standards that defines the interrelationship of content objects, data models and 
protocols such that objects are sharable across systems that conform to the same 
model. This specification promotes reusability and interoperability of learning content 
across Learning Management Systems (LMSs). SCORM is compatible to work with 
S1000D in developing tech pubs for training. The International S1000D - SCORM Bridge 
Project Team defined requirements for a specification that integrates authoring 
environments for SCORM-based learning content with S1000D Common Source 
Databases (CSDBs) used for technical manuals. 

Logistic Support Analysis (LSA) 

LSA is encompasses a key set of supportability tools which are typically initiated during 
design and development for purposes of supporting the O&S life cycle phase. The term 
"Logistics" has often been used by NASA only for functions like inventory management. 
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DoD uses the term more broadly, covering essentially all needs of O&S, but starting 
often during the design phase. Other industries have the same functions integrated into 
what they call systems engineering, product support, etc. DoD's recent change of terms 
from ILS to IPS helps describe the broader scope better. 

The analyses performed with LSA methods need to be documented. DoD developed LSA 
standards in the 1980s to best organize LSA information and manage in a data system, 
MIL-STD-1388-1 and MIL-STD-1388-2. These have been since used by many global 
industry users. The most recent version of the LSA data standard was MIL-STD-1388-2B. 
It was cancelled in 1996 during DoD reforms, yet it is still used today by many in industry. 
Replacement standard MIL-PRF-49506 was developed by DoD, and the UK developed 
DEF STAN 00-60. The MIL standard was then replaced in 2007 by the industry standard 
GEIA-STD-0007. ASD developed S2000M, S3000L, and S4000M (now S4000P) to 
accommodate LSA needs, and the AIA joined them in developing these with the whole 
S-series suite of specifications (standards). 

One of the key data elements in an LSA is the LSA Control Number (LCN). LCNs are key 
fields in LSAR databases which define a unique part application and have served to 
provide a visual indicator as the indenture level of a part. LCNs are limited to 18 
characters. The figure below shows the ISS LCN structure. 
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1st 
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3rd 

4th 

5th 
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8th 
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(A) 
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(H) 
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LCN Example 

S 

A 

F 

A 

D 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 
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Alternate LCN Codes (ALC) are used to define variants of an LCN item. 

NASA's Space Launch System (SLS) LCN structures are shown in the figures below. 



L r J S- 1 l 

/v 


C 


FA = Rack Assy 


AAA = Sub-Assy 
AA = Sub- Assy 
AA = Sub- Assy 


A = US Lab 


L S = International Space Station 


AAA = Screw, Capt 
AA = Cover, Front 


DA = ESS-MDM Internal 
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KEY 



SLS Program Flight Hardware LSACN Structure 



SLS Program Ground Support Equipment LSACN Structure 


KEY 



The MIL-STD-1388-2B standard requires defining each parent child relationship for each 
unique part application. In other words, despite the use of the same subassembly or 
NHA, each child must be linked to each new instance of the subassembly and unique 
LCNs must be assigned. Changes to one instance of the assembly require manual 
synchronization among all instances. An alternative data structure to the 1388-2B 
standard is a parent child table. This data structure requires indenturing a subassembly's 
components once and changes to the subassembly's BOM propagates through all part 
applications immediately. An example product breakdown structure using LCN's is 
shown below. 
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GEIA-STD-0007 standard is very similar to the MIL-STD-1388-2B. Like MIL-STD-1388-2B, 
it defines the data elements, structure, and business rules for logistics product data, but 
GEIA-STD-0007 does not prescribe how the data must be managed (e.g. relational 
tables). Instead, it specifies the requirements for the exchange/delivery of the data in 
an Extensible Markup Language (XML) format as prescribed by an XML Schema 
Definition (XSD). It requires defining each parent child relationship for each unique part 
application. Changes to one instance of the assembly require manual synchronization 
among all instances. An alternative data structure to the 1388-2B standard is a parent 
child table. This data structure requires indenturing a subassembly's components once 
and changes to the subassembly's BOM propagates through all part applications 
immediately. GEIA-STD-0007 established a common DoD baseline for Logistics Product 
Data (LPD), allowing DoD to progress towards an ISO 10303 solution. 


In comparing older LSA standards with GEIA-STD-0007, see the table below. 


MIL-STD-1388-2B 

MIL-PRF-49506 

GEIA-STD-0007 

518 Data Elements 

159 Data Products 

600 Data Elements 

104 Relational Tables 

No Relational Tables 

110 Entities 

9 Functional Areas 

No Functional Areas 

9 Functional Areas 

48 Reports 

8 Summaries 

24 Reports 

1 Master File (Full File) 
for Data Exchange 

No Master File 

1 Master File (XML Full 
File) for Data Exchange 

1 Database Repository 

User Defined Database 
Repository 

User Defined Database 
Repository 
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GEIA-STD-0007 has been working toward data exchange compatibilities with ISO 10303 
AP239 PLCS. The PLCS product breakdown structure is an equivalent approach to an 
LCN, but parallels usage in the design engineering and PDM domains. Each breakdown 
element contains a Breakdown Element Identifier (BEI). The figure below shows a PLCS 
approach compared to the LCN example used earlier. 


Breakdown Element 


Breakdown Element 


Truck 

— Relating view — 

Breakdown 

Element 

Usage 

— Related view — 

ENGINE 

(Gas) 

BEI = A 




BEI = A2 


(Randomly generated) (Randomly generated) 


In comparing to newer LSA standards, GEIA-STD-0007 can be structured as sets of Units 
of Functionality (UoF) that incorporate Unified Modeling Language (UML) diagrams for 
representing LPD business information requirements. This structure is similar to the 
approach used in the S-Series specifications (e.g. S2000M and S3000L standards). Each 
UoF, or functional area subset, contains a UML graphical representation along with set 
of associated definitions for each UML class. 

The Product Breakdown Structure UoF describes the information necessary to define a 
product, its variants, its breakdown constituents, and associated revisions (design 
iterations). The business information requirements are represented graphically in the 
figure below using a UML Class Diagram. 
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package Data[ ^ UoF Product Breakdown Structure ] 



S3000L is a more generic standard than GEIA-STD-0007 and MIL-STD-1388-2B. It is 
closer in structure to the UK's standard, DEF STAN 00-60. It gives good overall LSA 
information, but does not provide full support for all identified candidate item analysis 
activities. The data model covers just the LSA data elements that will typically be 
exchanged between a contractor and his subcontractors, partners, and customers. The 
scope of the data model includes: 

• Definition of LSA program and products to be supported. 

• Support early phases of LSA selection of candidate item and analysis activities. 

• Support LSA Failure Mode and Effect Analysis (FMEA), Special Events, and 
Damage Analysis. 

• Document results from Maintenance and Operational Task Analysis (MTA/OTA). 

It still requires defining each parent child relationship for each unique part application. 
Changes to one instance of the assembly require manual synchronization among all 
instances. An alternative data structure to the 1388-2B standard is a parent child table. 
This data structure requires indenturing a subassembly's components once and changes 
to the subassembly's BOM propagates through all part applications immediately. 
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The U.S. DoD's LOGSA white paper described a comparison between GEIA-STD-0007 
Logistics Product Data (LPD) and the S-series Specifications, as of 2013. They also 
compared SAE's TA-STD-0017 Product Support Analysis (PSA), adopted for DoD use in 
2013, which is relatable to MIL-STD-1388-1A and MIL-HDBK-502A. The figure below 
shows how they correlated the content in each standard. 


GEIA-STD-0007, Logistics Product Data 
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TA-STD-0017, Product Support Analysis 


S3000L Issue 1.0 used ISO 10303-239 PLCS edition 1 as the method for data exchange. 
To support this, the S3000L team published two Data Exchange Specifications (DEXs) 
using OASIS DEXlib. The two DEXs were published in 2011 and included: 

• DEX1A&D - Aerospace and defense business DEX for exchange of product 
breakdown for support 

• DEX3A&D - Aerospace and defense business DEX for exchange of a task set. 

Issue 1.1 just came out in July 2014. It is fully compatible with the new SX002D 
Common Data Model, which will form the core of the S-Series ILS specifications, 
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making them interoperable with each other. Thus, the new specification versions (such 
as the new S5000F, due out early 2015, or S2000M issue 6.0) will be able to exchange 
data with S3000L with no data conversion issues. 

The exchange of data for S3000L issue 1.1 is defined using XML and XML schema, which 
will be published on the S3000L website. An overview of the types of data exchanges 
supported by S3000L XML schemas is summarized in the figure below. 


Product 

development 

Engineering 
Support engineering 



External 
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Customer 


Product 
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Engineering 
Support engineering 
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(S1000D) 
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(S6000T) 


In service 
support 

(S5000F) 
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support 

(S2000M) 


In service 
support 

(S5000F) 


The method of mapping the S3000L data model to the S3000L XML schemas is done in 
accordance with the XML Schema Authoring Rules defined by the DMEWG. An added 
feature for LSA data exchange is the option to only exchange updates to complete 
(baseline) data, and it can accommodate minor and major changes. 

S3000L XML schemas will provide mappings to ISO 10303-239 PLCS edition 2 or OASIS 
PLCS PSM, in order to support continued use of the ISO PLCS standard. The rationale for 
introducing S3000L XML schemas as the basis for supporting S3000L data exchanges is 
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to allow for organizations that do not have the required PLCS skills to still support the 
S3000L specified data exchanges. 

ISO 10303 Standard for the Exchange of Product Model Data (STEP) 

STEP provides a comprehensive set of internationally-agreed integrated information 
models to address the problem of exchanging product information between dissimilar 
computer applications throughout the lifecycle of the product. 

Deployment of the STEP standard enables companies to have a proven single definition 
for all the product-related information related to individual products throughout their 
lifecycle, independent of changes in process and information technology. The standard 
will enable suppliers to deliver and receive support information in a consistent form, 
irrespective of the source. Interoperability is facilitated by the adoption of common 
subsets of the standard, known as Application Protocols to support particular 
information flows. 

In order to support specific business functions, STEP contains a number of subsets 
known as Application Protocols (APs), which constrain the standard to a particular 
business context. STEP also supports a wide range of IT services, ranging from simple 
file exchange through databases and language bindings to XML and schemas. STEP does 
not constrain the process modeling tools which can be used to express the context of 
the information exchanges. Of the few hundred STEP Aps, these are examples of those 
relevant to aerospace: 

• AP203 for configuration controlled 3D data, including full PDM information and 
parametrics (a common 3D "STEP" file neutral format) 

• AP209 for composite and metal structural analysis and related design 

• AP210 for printed circuit assemblies 

• AP212 for electrotechnical design and installation 

• AP214 for core data for automotive mechanical design processes (another 
common 3D "STEP" file neutral format) 

• AP219 for dimensional inspection 

• AP224 for process planning 

• AP232 for Technical Data Packages (TDP) 

• AP233 for systems engineering data representation 

• AP237 for computational fluid dynamics 

• AP238 for NC machining 

• AP239 for Product Life Cycle Support (PLCS) 

Given MIL-STD-31000 lacks the depth and berth to address a Digital Product Definition 
Package, guidance comes from the ISO 10303 STEP standards. The scope of STEP offers 
a "cradle to grave" standard that is a modularized architecture consisting of several 
Application Protocols (APs), each defining data from a specific business viewpoint of the 
integrated STEP information model. This is intended to provide software developers the 
flexibility of claiming conformance to specific domains of STEP. Two of the first APs 
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developed were AP 203 - Configuration Controlled 3D Design and AP 214 - Core Data 
for Automotive Mechanical Design Processes. They served as improvements over IGES 
in the area of 3D mechanical design. These protocols are being merged into one AP 
called AP 242 - Managed Model Based 3D Engineering, just released in 2014. 
Tangentially related to the work mentioned above, AP242 is being harmonized with 
AP239 edition 2 and other standards and this harmonization process could impact the 
AP239 edition 3 specification. 

ISO 10303-239 Product Life Cycle Support (PLCS) was first published in 2005 and allows 
STEP to accommodate the product support and configuration management domains. A 
key component of PLCS is the Activity Model defined in the IDEF0 modeling language, a 
language used to illustrate decisions, actions, and activities from a functional 
perspective. The Activity Model specifies the activities and the information flows 
between activities that the AP supports through data exchange. 

ISO 10303-239 Product Life Cycle Support (PLCS) was first published in 2005 and allows 
STEP to accommodate the product support and configuration management domains. 
The "PDM_Schema" created in 1999 as part of AP214 is what was brought forward to 
become ISO 10303-239 DEX1. A key component of 
PLCS is the Activity Model defined in the IDEF0 
modeling language, a language used to illustrate 
decisions, actions, and activities from a functional 
perspective. The Activity Model specifies the activities 
and the information flows between activities that the 
AP supports through data exchange. 

The PLCS Activity Model provides the foundation for 
the PLCS information model. The information model 
defines the entities and structures, or application 
modules, defined within the scope of the AP. It is 
represented in a language called EXPRESS and serves 
as the master PLCS schema. EXPRESS is a formal 
information requirements specification language (ISO 
10303-11) used to specify the requirements of the 
various ISO 10303 application protocols. The EXPRESS 
language focuses on the definition of entities, which 
represent objects of interest. The definition of an 
entity is in terms of its properties which are 
characterized by specification of a domain and the 
constraints on that domain. See a simplified subset of 
the PLCS EXPRESS schema to the right. 


ENTITY Product 

SUPERTYPE OF (ONEOF ( 
Breakdownelement, 
Document, 

Part)); 

id : STRING; 
name : STRING; 

description : OPTIONAL STRING; 

ENDENTITY; 

ENTITY Breakdown_element 

SUPERTYPE OF (ONEOF ( 
Functional_element, 
Physical_element, 
System_element, 
Zone_element)) 

SUBTYPE OF (Product); 

END_ENTITY; 

ENTITY Document 
SUBTYPE OF (Product); 

END_ENTITY; 

ENTITY Part 
SUBTYPE OF (Product); 

ENDENTITY; 
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The EXPRESS example contains an entity called Product with the subtypes 
Breakdown_element, Document, and Part. The Product entity also contains the id, 
name, and description attributes which are inherited by its subtypes. The 
Breakdown_element entity has the subtypes Functional_element, Physical_element, 
System_element, and Zone_element. The PLCS EXPRESS information model contains 
over 150 modules, 500 entities, and 1200 attributes and enables the functionality 
described in the figure below. 



For data exchange, PLCS utilizes two primary file transfer options defined by STEP: 

• ISO 10303-21 (Part 21) - ASCII exchange file format 

• ISO 10303-28 (Part 28) - XML exchange file format 

The Part 21 data files are validated with the EXPRESS schema and the Part 28 files are 
validated with an XSD derived from the EXPRESS schema. Both schemas contain the 
same basic content and are composed of generic entities such as Product, Breakdown, 
Part, Task, and Organization for example. Because the information model defined by 
PLCS is generic in nature to support the entire life cycle of a product, it has a scope that 
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is wider than most applications, business processes, or data exchange needs. Therefore, 
the concept of Data Exchange Specifications (DEXs) was created for narrowing the scope 
of PLCS. 

In most circumstances, it would be impractical for organizations to contract for the 
entire range of data specified in ISO 10303-239 PLCS. A DEX identifies a subset of the 
overall PLCS information model and allows organizations to acquire PLCS compliant data 
adapted to their unique business processes and activities. A DEX contains a schema, 
derived from the overall PLCS schema, containing only those PLCS entities required to 
support a specific business need. To aid organizations in DEX development and to 
promote the uptake of PLCS, the OASIS PLCS Technical Committee (TC) created an open 
source development environment called DEXlib. The TC also developed a set of 
templates, or predefined business objects, that specify collections of ISO 10303-239 
entities required to exchange a specific concept. Though these templates were created 
to assist in the DEX development, they are often viewed as complex by those not 
involved in their initial development. Nonetheless, DEXs can be developed using 
alternative methods to OASIS sponsored templates. PLCS DEXs are simply specifications 
on how to exchange information requirements in a manner compliant with ISO 10303- 
239. The figure below illustrates the relationship between the major PLCS components 
and STEP. 



The OASIS PLCS TC more recently created a second edition of DEXlib, called PLCSIib, 
focused on the development of Systems Modeling Language (SysML) based DEXs. The 
committee has derived a SysML Platform Specific Model (PSM) from the ISO 10303-239 
EXPRESS information model. An XML Schema was then derived from the SysML PSM to 
allow for XML implementations. 

The OASIS PSM appears to deviate from the ISO 10303-239 EXPRESS information model 
in several areas to improve the efficiency of the information model, thereby improving 
the efficiency of the end product (i.e. exchange file). However, these changes also 
appear to result in a split from the core STEP architecture resulting in a file structure 
that is not compliant with current STEP implementation methods. 
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DEXlib versus PLCSIib 

DEXlib (DEX edition 1) is based on the ISO 10303-239 Edition 1 schema while PLCSIib 
(DEX edition 2) is derived from ISO 10303-239 Edition 2 schema (does not directly 
support the schema of ISO 10303-239 Edition 2). There is no direct compatibility 
between DEXlib and PLCSIib so DEXs developed using DEXlib must undergo extensive re- 
work to be migrated to PLCSIib. Since TDI project proposal, industry and government 
entities have taken positions on PLCS and its different DEXs. All are waiting for how 
10303-239 edition 3 will resolve the differences. 


S-series ILS Specifications Schema and PLCS 

In awaiting ISO AP239 PLCS edition 3 and its associated data exchange development 
environment, all future S-series ILS specifications will follow the same XML schema 
approach as described in S3000L. The figure below illustrates how S-series ILS 
specification XML schemas are viewed with respect to ISO 10303-239 PLCS and OASIS 
PLCS PSM. 
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The S-series ILS specifications XML schemas are targeted to support data exchange at 
the Business Object Model (BOM) layer. However, each XML schema will also include 
the mapping details required for an unambiguous mapping of each element and 
attribute to PLCS in order to enable PLCS-based data exchanges and/or PLCS-based data 
consolidation. 


58 



LOGSA Schema and PLCS 

In a 2013 LOGSA white paper on PLCS and LPD, they describe an alternative to AP239 
DEXs similar to the ILS Spec Council's schema for the S-series. Rather than developing a 
DEX composed of OASIS templates, this approach primarily consists of a direct mapping 
from the GEIA-STD-0007 source elements to ISO 10303-239 target entities and 
attributes. This approach reflects a precise mapping and removes the potential for 
ambiguity among data exchange partners. The DEX mapping can be documented in 
HTML and included as an appendix to a future revision of GEIA-STD-0007, therefore 
providing a medium for publication. While OASIS templates and development 
environments such as DEXlib and PLCSIib play a valuable role in formulating generic DEXs 
standardized and published at the OASIS level, they lack substantive value in the 
development and standardization of an LPD business DEX. In addition, there is no 
method for publishing business DEXs in OASIS. 

CAD Data Exchanges 

Many people think of STEP as merely a neutral CAD file conversion format which can be 
exchanged between different CAD vendors. As this report's section on the overall ISO 
10303 STEP standard describes, STEP covers much more. That CAD conversion is covered 
by AP209 and AP214. Recently, AP242 was released, which combines the other two and 
updates these conversions. IGES and JT are other common neutral CAD exchange 
formats (not part of STEP), and there are some less common ones. These exchange tools 
are typical in vendor software and provide needed capabilities for programs using 
multiple CAD tools. However, the neutral conversions always have a risk of some loss of 
integrity. These risks have been accepted for years in industry. These must be 
considered again when performing CAD data exchanges using the TDI concept to pass 
data to entities outside of the design life cycle phase. PLCS is one method which may aid 
this exchange, whether from CAD to CAD environment or from CAD to non-design 
environment. 

Due to the need to exchange CAD to CAD in many formats, and the issue of exchange 
integrity, NASA is currently drafting NASA-HDBK-0009, Engineering Model Maturity 
Levels (EMML): Model Definitions. This draft states that definition of model maturity is 
missing in both the models being shared and the Data Requirements Descriptions 
(DRDs) representing the contracted deliverable. EMML is intended to enhance the 
integrity and definition of the model itself with regard to digital integrity and definition. 

Efforts to exchange CAD data to entities outside design have been attempted, but 
challenges have been discovered due to many variations in CAD model definition or 
product structure. Some proprietary vendor solutions have been developed for 
exchanges using certain scenarios or vendor tools. NASA's EMML handbook could aid 
this issue for programs who use it effectively for contracting. 

On industry white paper described the production of Computer-Based Training (CBT) 
using S1000D and SCORM standards. They reused CATIA 3D models in S1000D data 
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modules (DM). 3D models were reduced and converted to 3D XML. Next, scripts were 
developed to generate a mapping between the 3D XML from CATIA and the XML from 
the S1000D DM's. Mechanics working on an aircraft can now perform Computer-Based 
Training and Simulation Scenarios in a web-based system. Any changes to aircraft design 
are reflected in the CATIA models and those changes are mapped (via the 3D XML) to 
the S1000D based work instructions. This means that aircraft mechanics can now easily 
update their Training and Simulation environments with minimal effort. 

Evaluation of industry standard data exchanges of CAD data directly with S1000D data 
is available, but appears to be not well developed yet. PTC described to the TDI team 
that they have a vendor solution based on about half proprietary and half industry 
standard methods. The recently-formed S1000D Model-Based Enterprise Task Team 
(MBETT) is currently gathering all known methods of getting CAD data into S1000D and 
evaluating best recommendations to update the S1000D standard for this. 

LOngTerm Archiving and Retrieval (LOTAR) 

The LOTAR project is designed to provide a capability to store digital product 
information in a standard neutral form that can be read and reused throughout its 
lifecycle, independent of changes in the IT application environment originally used to 
create it. The multi-part standard covers both the information content and the 
processes required to ingest, store, administer, manage and access the information. 

LOTAR brings together the work started under the AIA Manufacturing Maintenance and 
Repair Committee with similar work in ASD-Europe, under the auspices of the 
International Aerospace Quality Group (IAQG). Standards with identical technical 
content represented by LOTAR are: 

• NAS9300 series standards in the US. 

• EN9300 series standards in Europe. 

The European and the American aerospace industry associations (ASD and AIA) selected 
EXPRESS as the open, maintained standard information language for the purpose of 
digital archiving. LOTAR allows the re-use of existing designs in both new products and 
updates to existing products and ensures successful retention of data for legal purposes. 

The life cycle of applications and storage technologies hast to be considered by setting 
up a long term archiving and retrieval standard. Approximately every three years a 
change in the application technology and every ten years in the technology of storage 
and retrieval happen. In comparison with an archiving period of fifty up to one hundred 
years in the aerospace and defense industry the technology life cycle plays a major role. 
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H-4 Policies/Positions on TDI Standards 

This section describes the various policies and positions of industry and government 
organizations, including NASA, in reference to the standards evaluated by the TDI 
project. General interoperability requirements are also referenced. 

AlA's Engineering Data Interoperability Group (EDIG) recommended in a 2008 position 
paper and 2009/2013 guide that AIA Member companies and Suppliers transition to a 
Standards-based interoperability solution utilizing PLCS (ISO 10303-239) and its 
associated DEXs. NASA is an AIA member. 

The ASD/AIA ILS Spec Council's DMEWG came out with a new direction in 2014 on a 
standard exchange mechanism between the S-Series specifications. In the DMEWG 
Charter, the ILS Spec Council had directed the use of ISO 10303-239 PLCS, but had not 
specified which edition to use nor the Data Exchange (DEX) method to be used. After 
PLCS DEX changes, they decided to put in place a new DEX development capability, and 
it is believed that this will be harmonized with a future Edition 3 of the ISO 10303-239 
PLCS data model environments. Their decision included reviews of similar evaluations 
and conclusions of the PLCS AP239 differences by the following various standards 
communities: 

• SAE Life Cycle Logistics Supportability (LCLS) Committee, who manages GEIA- 
STD-0007 

• Europe's ASD Strategic Standardization Group (SSG) 

• Airbus Group Standards Steering Committee (SSC) 

• The OASIS PLCS TC also presented their evaluations at meetings with the 
DMEWG, but the DMEWG still chose to depart from PLCSIib. 

In 2014, the ASD/AIA ILS Spec Council's new short term direction is to implement S- 
Series specifications data exchange using a "bespoke" (i.e. "custom") XML schema 
approach with a direct mapping to ISO PLCS edition 2. As a long term objective, they 
support development of ISO PLCS edition 3 and support the eventual re-integrating of 
the S-Series specification data exchange with an anticipated ISO PLCS edition 3. 
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Various NASA policies have begun to touch on TDI and related standards in the last 5- 
10 years. 

NPR 7120.10 "Technical Standards for NASA Programs and Projects" (rev. 2012): NASA 
is required to use industry standards where no comparable NASA standard exists. 

NPR 7120.9 "Product Data & Life-Cycle Mgt (PDLM) for Flight Programs & Projects" (rev. 
2011): Requirements promote interoperability for PDLM goals. 

NASA-HDBK-0009, "Engineering Model Maturity Level (EMML): Model Definitions", 
(draft in work): Presents practices and procedures to define a consistent approach for 
exchanging critical program and digital project data (3D models and simulations), 
inclusive of maturity and states, across multiple NASA centers and domains. 

NASA-HDBK-0008, NASA Product Data and Life-Cycle Management (PDLM) Handbook; 
Applicable & Ref Documents: 

• ISO 10303-239 Product Life Cycle Support (PLCS) 

• ISO 10303-203 & -214 (3D CAD neutral STEP exchange files) 

• 6.5.1 Exchanging and Distributing 3D Models: The most important requirement 
relating to the documentation and archiving of engineering data is that all 
relevant information be stored in a format that can be read irrespective of a 
specific IT infrastructure and after a long period of time; in the aerospace 
industry, for example, the Long Term Archiving and Retrieval (LOTAR) activity 
that addresses archiving of data for long life-cycle programs. 

NPD 7500.1, Program and Project Logistics Policy; Applicable & Ref Documents: 

• GEIA-STD-0007, Logistics Product Data 

• ASD S3000L, Int'l Procedure Specification for Logistic Support Analysis 

• GEIA-STD-927, Common Data Schema for Complex Systems 

o Uses ISO 10303-239 PLCS as one of the integration models. 

• Designing and Assessing Supportability in Department of Defense (DoD) Weapon 
Systems: A Guide to Increased Reliability and Reduced Logistics Footprint, (2003) 

o Superseded by Defense Acquisition Guide, & Product Support Manager 
Guidebook, 2011. 

o Product Support Manager Guidebook refers to S1000D for lETMs. 
GSDO-PLN-1024, GSDO Integrated Logistics Support Plan; Applicable & Ref Documents: 

• GEIA-STD-0007, Logistics Product Data 

• ASD S3000L, Int'l Procedure Specification for Logistic Support Analysis 
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CEV-T-011, "Project Orion, Integrated Logistics Support Plan"; Applicable & Ref 
Documents: 

• NPD 7500. 1A, Program and Project Logistics Policy 

• Designing and Assessing Supportability in Department of Defense (DoD) Weapon 
Systems: A Guide to Increased Reliability and Reduced Logistics Footprint, (2003) 

• 3.1 TECHNICAL DOCUMENTATION/INTERACTIVE ELECTRONIC TECHNICAL 
MANUALS & 3.2 LOGISTICS SUPPORT ANALYSIS TOOLS AND DATABASES: "To 
ensure commonality, Orion Integrated Logistics and all subcontractors will use 
...applications compatible with EAGLE" 

In 2004, the U.S. Navy issued policy on the procurement and delivery of digital product 
and technical data. The policy requires product data, engineering design and 
manufacturing data (CAD/CAM/CAE), 3-D vector data, and product model data be 
delivered in accordance with International Organization for Standardization (ISO) 10303, 
Standard for the Exchange of Product Model Data (STEP). The Under Secretary of 
Defense for Acquisition, Technology, and Acquisition (USD (AT&L)) highlighted this 
policy in 2005 and requested the Army and Air Force to implement a similar approach 
that adopts ISO 10303 to enhance interoperability between Services, depots and 
contractors. As a result, the Air Force issued Air Force Instruction (AFI) 63-101, 
Acquisition and Sustainment Life Cycle Management in 2009, which requires Program 
Managers to use STEP Application Protocol (AP) 239 for acquiring engineering data on 
acquisition programs 

ISO 10303 AP239 PLCS was ratified as a NATO standard in February 2008 under 
Standardization Agreement (STANAG) 4661, which states that member nations agree to 
apply AP239 for product data management in cooperative NATO acquisition programs. 
NATO Guidance on Life Cycle Costing (ALCCP-1) recommends use of PLCS for data 
collection. 

Although the U.S. Army does not have an official policy on STEP implementation, it does 
require the use of interoperability standards for data exchange. In addition, AR 700-127, 
Integrated Product Support (IPS) requires the use of SAE GEIA-STD-0007, Logistics 
Product Data as the contractual method for acquiring and documenting data logistics 
product data resulting from the product support analysis process. GEIA-STD-0007 was 
developed as an intermediate strategy for codifying a logistics product data exchange 
mechanism for DoD and industry partners. 

The U.S. Army Logistics Support Activity (LOGSA) has been involved with various working 
groups and boards for the Aerospace and Defence Industries Association of Europe 
(ASD) S-series specifications, PDES Inc., the Organization for the Advancement of 
Structured Information Standards (OASIS), and SAE International standards. After 
conducting an analysis, LOGSA determined that the functional areas and data elements 
contained in SAE GEIA-STD-0007 clearly fell within the scope of ISO 10303-239 PLCS. The 
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functional areas of the standard were used as building blocks for creating a logistics 
product data DEX that could be tailored to organizational needs. The preliminary DEXs 
were completed using the OASIS DEXlib methodology which utilizes templates based on 
ISO 10303-239 Ed. 2. However, during this time, another OASIS DEX development 
methodology emerged called PLCSIib. This methodology was a labeled as a replacement 
for DEXlib but it was not based on ISO 10303-239 Ed 2, but a new schema called the 
OASIS Platform Specific Model (PSM) that deviated from the formal ISO 10303-239 Ed 2 
schema. This work became an OASIS committee specification called Product Life Cycle 
Support Version 1.0. Despite the PLCS name, it still remains an OASIS committee 
specification and has yet to be introduced as a basis for developing an ISO 10303-239. 
Ed 3. 

As a result of the instability and lack of direction within OASIS, LOGSA developed a new 
independent alternative for creating an ISO 10303-239 PLCS based DEX. Rather than 
developing a DEX composed of OASIS templates, the LOGSA approach removes the 
abstraction and primarily consists of a direct mapping from the SAE GEIA-STD-0007 
source elements to ISO 10303-239 target entities and attributes. This approach reflects 
a simple and precise mapping and removes the potential for ambiguity among data 
exchange partners. The mapping can be documented in HTML and included as an 
appendix to a future revision of SAE GEIA-STD-0007, therefore providing a medium for 
publication. This method eliminates the risk posed by the changing DEX development 
methodologies within OASIS. The method is also ISO 10303-239 Ed. 2 based, not OASIS 
committee specification based. 

However, due to the many challenges and uncertainties surrounding OASIS and ISO 
10303-239 in the near term, LOGSA recommended to the SAE International Life Cycle 
Logistics Supportability (LCLS) technical committee (the committee that governs SAE 
GEIA-STD-0007) that short term efforts should be focused on enhancing SAE GEIA-STD- 
0007 as an intermediate step in migrating to an ISO 10303-239 solution (presumed to 
be ISO 10303-239 PLCS Ed. 3) in the future. In 2013, the SAE LCLS committee agreed 
with LOGSA's recommendations to shelve ISO 10303-239 PLCS efforts for the short term 
and focus on improving the existing SAE GEIA-STD-0007 data exchange structure by 
making it more compatible with ISO 10303-239 PLCS. 

According to LOGSA, as currently written, each S-Series specification will require an 
additional DoD standard (and possibly multiple standards to support each of the 
different services) to appropriately contract in accordance with DoD guidance and 
regulations. They cite the example of the required MIL-STD-3031 and MIL-STD-3048 in 
order to implement for S1000D. This similar pattern would have to be followed in order 
to contract for any of the S-Series specifications. They also note that S1000D is widely 
used by industry and has a well-organized support structure. The U.S. Army/Marine 
Corps and Air Force have developed implementation standards that adapt S1000D to 
their requirements. In LOGSA's April 2014 white paper, they recommend that the DoD 
continue to use the SAE and U.S. DoD standards and handbooks for product support 
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analysis and LPD, and that DoD implementation of S-series specifications should be 
based on policy and guidance of each DoD service. Future development of the S-series 
may influence future DoD usage. 

The requirement for long-term retention of data varies by industry. The U.S. Federal 
Aviation Administration (FAA) for the commercial aviation industry has a regulatory 
requirement to retain the original design data for 50 years or more. This requirement 
can be found in Order 8110.4, which is available at www.faa.gov . The defense industry 
has an incentive to retain data for the life of a deployed weapon system. In other 
industries, the requirements for product liability require the retention of data for the 
life of the product plus 7 to 10 years depending on industry. 
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